Version: (using KDE KDE 3.2.2) Installed from: Debian testing/unstable Packages A URL such as <http://example.com/foo> may be use content negotiation to access a final resource such as <http://example.com/foo.html>. The detail of the final resource is hidden from the user (that is, it doesn't appear in the URL bar). Now, if the document that <http://example.com/foo> resolves to happens to contain relative anchors, Konqueror will not compute their absolute URL correctly. Instead of <http://example.com/foo#bar>, it will produce <http://example.com/foo.html#bar>. I have set up a test at <http://memebeam.org/john/tests/konq-relative-anchor-bug>. Hover over the link to see the incorrect relative URL.
One example of why this is a bug that needs to be fixed is this: 1) load 500KB page as <http://example.com/foo> 2) follow local anchor in the page-- in KDE's buggy case it's <http://example.com/foo.html#bar> 3) the entire page is downloaded again, since a different URL was used
The server sends the following HTTP header: Content-Location: konq-relative-anchor-bug.html And that is used as the base url for future requests as per r1.773 of khtml_part.cpp to fix http://bugs.kde.org/show_bug.cgi?id=51185 Given the bugreporter of BR51185 I think thats the correct behavior.
*** Bug 59654 has been marked as a duplicate of this bug. ***
*** Bug 95240 has been marked as a duplicate of this bug. ***
*** Bug 102236 has been marked as a duplicate of this bug. ***
*** Bug 80282 has been marked as a duplicate of this bug. ***
*** Bug 117448 has been marked as a duplicate of this bug. ***
*** Bug 85239 has been marked as a duplicate of this bug. ***
Given the number of duplicates o fthis bug, this is a rampant problem, proably due to mis-configured proxies. I ackgnowlegde that Konqueror is technically doing "the right thing" here, but the fact that IE and Mozilla both display the pages properly gives the false impression that Konqueror is the one that is broken, which is never a good thing. There is a very simple fix. Why can't KHTML just fall-back to the current web page base URL if the one specified in the Content-Location header does not work for the requested resource? It seems to me like this would be very simple to do, and would allow konqueror to both obey the RFC and also display these pages properly.
You mean, after the 100 items that we tried to download failed to download (which can take up to a minute, even for the first one) we should try to download everything again by ignoring what the RFC says? In other words, you want to reopen Bug 51185, revert the fix that went into it and mark it as WONTFIX.
> You mean, after the 100 items that we tried to download failed to download (which can take > up to a minute, even for the first one) we should try to download everything again I dont see why one couldn't just use the notifyFinished signal to check if the item accually succeeded, and if it failed, to re-try using the different base URL. They may fail in a minute, they may fail almost instantly. It depends on the errorneous header and what it is pointing at - if it is pointing at the right server but the wrong location you will get a 404 right away. And this isn't the same as before 51185, before 51185 tried the page base URl *first*, ignoring the Content-Location header. The suggestion is simply to follow the RFC but *fall back* to tbe broken behaviour so that Konqeror is not so broken in the eyes of the user. Frankly, I don't see how it is any different from how Konqueror supports some DOM events that are not in the W3C specs, to be compliant with other browsers. Like you said, "the specs don't mean anything if no one follows them", and no one is following this one, at least no one that matters. Konqueror alone is not going to make much of an impact simply by being stubborn.
Nope. We have to revert the fix and make KHTML work! And since I am responsible for this patch back in the 3.1 days, I am reverting it. Actually I am only commenting out the code in khtml_part.cpp. Had I known the issues involved I would have fixed this much much sooner.
Here is the relevant discussion by the Mozilla devs: https://bugzilla.mozilla.org/show_bug.cgi?id=109553 Here is what the Opera devs did: http://groups.google.com/group/opera.general/msg/9496b1b58a876b6b
SVN commit 490870 by adawit: Revert the fix for BR# 51185. It breaks far too many sites in the name of standards compliance. None of the other major browsers support it. And many web servers implement it incorrectly. See BR# 82747 for details. BUG: 82747 M +4 -1 khtml_part.cpp --- branches/KDE/3.5/kdelibs/khtml/khtml_part.cpp #490869:490870 @@ -1643,10 +1643,13 @@ if( !qData.isEmpty()) d->m_doc->processHttpEquiv("refresh", qData); - // Support Content-Location per section 14.14 of RFC 2616. + // DISABLED: Support Content-Location per section 14.14 of RFC 2616. + // See BR# 51185,BR# 82747 + /* QString baseURL = d->m_job->queryMetaData ("content-location"); if (!baseURL.isEmpty()) d->m_doc->setBaseURL(KURL( d->m_doc->completeURL(baseURL) )); + */ if ( !m_url.isLocalFile() ) { // Support for http last-modified