You need to
before you can comment on or make changes to this bug.
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://188.8.131.52/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).
Do you happen to have a URL that reproduces this behaviour that can be used for testing?
The URL is mentioned above, it's <http://test.confuego.org/57819#c13>.
*** Bug 24701 has been marked as a duplicate of this bug. ***
Created an attachment (id=30621) [details]
Keep the anchor from the last URL when encountering a server redirect
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.
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.
*** Bug 28368 has been marked as a duplicate of this bug. ***
It sounds like this behavior is well understood, but just for reference, here are a couple of links which reference the issue:
In limited testing I found Firefox (3.5.3) & Chrome (184.108.40.206) both preserve the fragment identifier during redirects. Safari (4.0.4) and the latest nightly webkit do not.
The link in this story exhibits the behavior. As stated above, Firefox and Chrome reach the correct Twitter page, but Webkit.app doesn't.
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
I have setup a test URL
which redirects to
and then is redirected to
which should have the final loaded page be
That was a more complex example but covers the edge cases that should be used in testing
should finally result in
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
with a redirect resulting in
is what this bug is about.
a simple .htaccess i am using
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
(In reply to comment #2)
The radar is actually <rdar://problem/3225447>