Bug 82747

Summary: The Content-Location non-bug
Product: [Applications] konqueror Reporter: John Belmonte <john>
Component: khtmlAssignee: Konqueror Developers <konq-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: falso, jason, kdebugs, matofesi, o-z, t35t0r
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: Linux   
Latest Commit: Version Fixed In:

Description John Belmonte 2004-06-03 05:36:34 UTC
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.
Comment 1 John Belmonte 2004-06-08 22:50:33 UTC
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
Comment 2 Waldo Bastian 2004-06-09 22:37:46 UTC
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.
Comment 3 Thiago Macieira 2004-12-16 11:44:15 UTC
*** Bug 59654 has been marked as a duplicate of this bug. ***
Comment 4 Thiago Macieira 2004-12-16 11:44:38 UTC
*** Bug 95240 has been marked as a duplicate of this bug. ***
Comment 5 Thiago Macieira 2005-03-23 03:57:00 UTC
*** Bug 102236 has been marked as a duplicate of this bug. ***
Comment 6 Thiago Macieira 2005-05-27 13:42:46 UTC
*** Bug 80282 has been marked as a duplicate of this bug. ***
Comment 7 Thiago Macieira 2005-12-01 18:52:21 UTC
*** Bug 117448 has been marked as a duplicate of this bug. ***
Comment 8 Thiago Macieira 2005-12-01 19:27:12 UTC
*** Bug 117448 has been marked as a duplicate of this bug. ***
Comment 9 Thiago Macieira 2005-12-01 19:52:59 UTC
*** Bug 117448 has been marked as a duplicate of this bug. ***
Comment 10 Thiago Macieira 2005-12-22 15:06:36 UTC
*** Bug 85239 has been marked as a duplicate of this bug. ***
Comment 11 Jason Keirstead 2005-12-22 15:32:11 UTC
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.



Comment 12 Thiago Macieira 2005-12-22 19:33:41 UTC
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.
Comment 13 Jason Keirstead 2005-12-22 19:50:32 UTC
> 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.
Comment 14 Dawit Alemayehu 2005-12-23 14:49:00 UTC
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.
Comment 15 Dawit Alemayehu 2005-12-23 14:51:31 UTC
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
Comment 16 Dawit Alemayehu 2005-12-23 14:58:10 UTC
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