Bug 24175 - URL Redirect Loses Fragment
: URL Redirect Loses Fragment
Status: NEW
: WebKit
Page Loading
: 528+ (Nightly build)
: Macintosh Mac OS X 10.5
: P2 Normal
Assigned To:
:
: InRadar, ReviewedForRadar
:
:
  Show dependency treegraph
 
Reported: 2009-02-25 16:08 PST by
Modified: 2012-02-25 11:32 PST (History)


Attachments
Keep the anchor from the last URL when encountering a server redirect (953 bytes, patch)
2009-05-23 14:09 PST, Matt Good
no flags Review Patch | Details | Formatted Diff | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2009-02-25 16:08:26 PST
When following a redirect from a server (301 & 302, possibly others), any fragment on the URL is dropped.  For example, if example.com/old redirects to example.com/new, then attempting to load example.com/old#anchor will load example.com/new, while other browsers (FireFox 3 and Chrome confirmed, possibly others) will load example.com/new#anchor instead.  This happens with Safari 3.2 (Mac), Safari 4.0 Beta (Mac), and the latest nightly build of WebKit (Mac).

This seems to be the same as a KHTML bug reported in 2003 at http://bugs.kde.org/show_bug.cgi?id=57819 which is currently unreachable, but cached at http://74.125.95.132/search?q=cache:5VU5AvOFt64J:bugs.kde.org/show_bug.cgi%3Fid%3D57819+anchor+redirect+preserve&hl=en&ct=clnk&cd=1&gl=us&client=safari  The bug history there mentions an example URL of http://test.confuego.org/57819#c13 which redirects to the bug description itself (dropping #c13 under Safari).
------- Comment #1 From 2009-02-25 16:14:53 PST -------
Do you happen to have a URL that reproduces this behaviour that can be used for testing?
------- Comment #2 From 2009-02-25 16:15:05 PST -------
<rdar://problem/6623841>
------- Comment #3 From 2009-02-26 10:52:09 PST -------
The URL is mentioned above, it's <http://test.confuego.org/57819#c13>.
------- Comment #4 From 2009-03-21 04:21:58 PST -------
*** Bug 24701 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2009-05-23 14:09:15 PST -------
Created an attachment (id=30621) [details]
Keep the anchor from the last URL when encountering a server redirect
------- Comment #6 From 2009-05-23 14:23:47 PST -------
The attached patch applies to trunk@44087 and produces the expected result with the above test url.

Alternatively this change could be moved somewhere higher up in the stack like MainResourceLoader::willSendRequest.
------- Comment #7 From 2009-05-24 00:44:59 PST -------
Would you be willing to submit a patch with layout tests and a ChangeLog for review? See <http://webkit.org/coding/contributing.html>.

I don't know which of the places you suggested for this code is better, but the person reviewing the patch hopefully will.
------- Comment #8 From 2009-08-16 18:58:04 PST -------
*** Bug 28368 has been marked as a duplicate of this bug. ***
------- Comment #9 From 2010-02-03 07:49:37 PST -------
It sounds like this behavior is well understood, but just for reference, here are a couple of links which reference the issue:

http://www.w3.org/TR/cuap#uri
http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt

In limited testing I found Firefox (3.5.3) & Chrome (4.0.249.49) both preserve the fragment identifier during redirects. Safari (4.0.4) and the latest nightly webkit do not.
------- Comment #10 From 2011-04-24 08:34:19 PST -------
The link in this story exhibits the behavior. As stated above, Firefox and Chrome reach the correct Twitter page, but Webkit.app doesn't.
http://www.bbc.co.uk/news/world-us-canada-13179413
------- Comment #11 From 2011-11-17 08:27:05 PST -------
On the desktop this bug exists in safari & webkit standalone but not in chrome.  

On the mobile it exists in android and ios.

It should probably be handled according to 
http://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt

I have setup a test URL

http://web.cip.gatech.edu/webkit/redirection-fragment/base.html

which redirects to 

http://web.cip.gatech.edu/webkit/redirection-fragment/fragment.html#somefragment

and then is redirected to

http://web.cip.gatech.edu/webkit/redirection-fragment/final.html

which should have the final loaded page be

http://web.cip.gatech.edu/webkit/redirection-fragment/final.html#somefragment

That was a more complex example but covers the edge cases that should be used in testing

because 

http://web.cip.gatech.edu/webkit/redirection-fragment/base.html#newfragment

should finally result in 

http://web.cip.gatech.edu/webkit/redirection-fragment/final.html#somefragment

because the inclusion of the fragment from the server redirect should override my local requested one but without the inclusion it should use my local one

But the basic example of using

http://web.cip.gatech.edu/webkit/redirection-fragment/fragment.html#otherfragment

with a redirect resulting in  

http://web.cip.gatech.edu/webkit/redirection-fragment/final.html#otherfragment

is what this bug is about.

a simple .htaccess i am using

.htaccess
# Redirection
Redirect /webkit/redirection-fragment/fragment.html http://web.cip.gatech.edu/webkit/redirection-fragment/final.html
Redirect /webkit/redirection-fragment/base.html http://web.cip.gatech.edu/webkit/redirection-fragment/fragment.html#somefragment
------- Comment #12 From 2012-02-25 11:32:14 PST -------
(In reply to comment #2)
> <rdar://problem/6623841>

The radar is actually <rdar://problem/3225447>