The rationale behind chaging KURL constructor.

As I understand this particular form -- KURL(KURL, QString) -- is primarily intended to change a _part_ of the URI (namely _local_ part), but #fragment (as it's named in RFC) is neither a part of the absoluteURI nor of the relativeURI.

The http.cc patch seems ok. Note that kio-http doesn't normally use the
reference, but when it gets the redirection it will forward the redirected-to
URL to the application. At this point the reference gets lost, because the
application will start using the new URL without reference. 

It's strange this little issue isn't fixed yet. So please commit the patch and
mark the bug as resolved.

I fail to see where the bug is.

If a site redirected to http://host/res2, it redirected to http://host/res2, not http://host/res2#reference.

> I fail to see where the bug is.

The bug is in understanding what the fragment identifier is.

First, you must reread RFCs (eg. RFC2396) to see:

   When a URI reference is used to perform a retrieval action on the
   identified resource, the optional fragment identifier, separated from
   the URI by a crosshatch ("#") character, consists of additional
   reference information to be interpreted by the user agent _after_ the
   _retrieval_ action has been successfully _completed_.  As such, it is
   _not_ part of a URI, but is often used in conjunction with a URI.

   The semantics of a fragment identifier is a property of the data
   resulting from a retrieval action, regardless of the type of URI used
   in the reference.

Second, you should browse through http://www.w3.org/DesignIssues/Fragment.html and http://skrb.org/ietf/http_errata.html for clues.

Third, you may confirm the expected behaviour running other browsers.

> If a site redirected to http://host/res2, it redirected to http://host/res2, not http://host/res2#reference.

That #reference is intended to be used as a so-called 'fragment identifier' in the retrieved object, and redirection is just a mean to present another object istead of the requested.

Ok, I understand now and it makes sense.

If you try to go to URI1#reference and UR1 is redirected to URI2, then what you really want is to go to URI2#reference.

I'll apply the patch.

> If you try to go to URI1#reference and UR1 is redirected to URI2, then what you really want is to go to URI2#reference.

Yes. With one small clarification: according to http://www.w3.org/TR/webarch/

    Interpretation of the fragment identifier is performed solely by
    the agent that dereferences a URI; the fragment identifier is not
    passed to other systems during the process of retrieval. This means
    that some intermediaries in Web architecture (such as proxies) have
    no interaction with fragment identifiers and that redirection
    (in HTTP [RFC2616], for example) does not account for fragments.

when I try to go to URI1#reference, I just send plain URI1 to the server and
then try to find the #reference inside whatsoever is returned.


> I'll apply the patch.

Please do. But keep in mind I restricted action to the same host in the
original patch which is not right. My first consideration was ah-h...
"security"? I was wrong.

--- kioslave/http/http.cc.orig        Fri Mar 17 15:19:08 2006
+++ kioslave/http/http.cc     Fri Apr  4 02:11:07 2006
@@ -3590,6 +3590,9 @@
       error(ERR_ACCESS_DENIED, u.url());
       return false;
     }
+    // Preserve #reference
+    if (m_request.url.hasRef() && !u.hasRef()) 
+      u.setRef(m_request.url.ref()); 
     m_bRedirect = true; 
     m_redirectLocation = u; 

I don't agree. I don't think we should expose the fragment when doing a
cross-protocol or cross-site redirection (imagine if it came from https into
http).

I'll apply your original patch.

SVN commit 526404 by thiago:

Keep the fragment when doing redirections. (the HTTP requests and
redirections don't include fragments; it's a browser thing).

BUG:124654


 M  +10 -0     http.cc  


--- branches/KDE/3.5/kdelibs/kioslave/http/http.cc #526403:526404
@@ -3596,6 +3596,16 @@
       error(ERR_ACCESS_DENIED, u.url());
       return false;
     }
+
+    // preserve #ref: (bug 124654)
+    // if we were at http://host/resource1#ref, we sent a GET for "/resource1"
+    // if we got redirected to http://host/resource2, then we have to re-add
+    // the fragment:
+    if (m_request.url.hasRef() && !u.hasRef() &&
+        (m_request.url.host() == u.host()) &&
+        (m_request.url.protocol() == u.protocol()))
+      u.setRef(m_request.url.ref());
+    
     m_bRedirect = true;
     m_redirectLocation = u;
 

SVN commit 526405 by thiago:

INTEGRATION:/branches/KDE/3.5/kdelibs/kioslave/http 526404
Keep the fragment when doing redirections. (the HTTP requests and
redirections don't include fragments; it's a browser thing).

CCBUG:124654


 M  +10 -0     http.cc  


--- trunk/KDE/kdelibs/kioslave/http/http.cc #526404:526405
@@ -3512,6 +3512,16 @@
       error(ERR_ACCESS_DENIED, u.url());
       return false;
     }
+
+    // preserve #ref: (bug 124654)
+    // if we were at http://host/resource1#ref, we sent a GET for "/resource1"
+    // if we got redirected to http://host/resource2, then we have to re-add
+    // the fragment:
+    if (m_request.url.hasRef() && !u.hasRef() &&
+        (m_request.url.host() == u.host()) &&
+        (m_request.url.protocol() == u.protocol()))
+      u.setRef(m_request.url.ref());
+    
     m_bRedirect = true;
 
     if (!m_request.id.isEmpty())

Thiago, as I've stated before the fragment identifier is NOT supposed to be
sent to the server. And I've checked and rechecked if kio_http conforms to the
expected behaviour. To all my knowledge it does. Please reread my citation from
the http://www.w3.org/TR/webarch/ and make some tests. You could also look
through the codebase.

It's not being sent.

However, I can still reproduce the problem, even after applying the fix.

On Tuesday 04 April 2006 23:03, Thiago Macieira wrote:

> It's not being sent.


So why not to remove restrictions on the host and the protocol?

> However, I can still reproduce the problem, even after applying the fix.


I've tested 3.4.2, 3.5.1, 3.5.2. Using this patch for 4 days without a 
problem.

Here's a simple testcase: http://www.intramail.ru/ref_test#faraway

You should see a word of cheer on the top, not 404. The text in the Location 
should also include #faraway.

JavaScript still sees it. So, unless we're redirecting inside the same host,
don't propagate it.

> JavaScript still sees it.

So what? You are mistaken the same way I used to be. It's just the first impulse of any security related person -- they see it, they can use it. What a potential "attacker" can do then? It's easier for him simply to fetch the original object and get _all_ the anchors, not one, from there. Saying nothing of the actions he has to undertake to get you request redirected. IMHO, you are fighting with windmills.

Cross-domain scripting isn't allowed. You cannot fetch the object if it came
from another domain.

> Cross-domain scripting isn't allowed.

Could you please describe step by step the worst case scanario of the "cross-domain scripting" using 3XX redirection and the fragment identifier? What objects will be compromised?