Version: (using KDE ) OS: FreeBSD In the case where there was a #reference with the original URI, e.g. 'http://host/res1#reference' redirects to 'http://host/res2', kio_http does NOT propagate #reference from the original URI to the new one. I'm yet not shure whether it's KURL what needs to preserve m_strRef_encoded in KURL(KURL, Qstring) constructor or should kio_http be altered. I prefer former personally. Patches for both cases: --- kurl.cpp.orig Sat Nov 19 14:09:18 2005 +++ kurl.cpp Fri Mar 31 09:55:10 2006 @@ -610,6 +610,9 @@ m_strUser = _u.m_strUser; m_strPass = _u.m_strPass; } + // Preserve #ref if applicable (is it feasible if hosts differ? guess not). + if (!_u.m_strRef_encoded.isEmpty() && m_strRef_encoded.isEmpty() && (_u.m_strHost == m_strHost) && (_u.m_strProtocol == m_strProtocol)) + m_strRef_encoded = _u.m_strRef_encoded; cleanPath(false); } } --- http.cc.orig Fri Mar 17 15:19:08 2006 +++ http.cc Fri Mar 31 10:16:28 2006 @@ -3590,6 +3590,9 @@ error(ERR_ACCESS_DENIED, u.url()); return false; } + // Preserve #ref + 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; PS. Patched are mutually exclusive.

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?