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://22.214.171.124/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 attachment 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 (126.96.36.199) 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>
Surprisingly, this bug is still is Safari 7 and as annoying as ever. Going to get worse before it gets better with the amount of Backbone-style fragment based routing these days.
Created attachment 240405 [details]
Unfortunately, this issue is still open but more and more H5 pages expect it has correct behavior.
For more details, please refer to the discussion on StackOverflow:
I summit this patch for review without testing html, I am unfamiliar with Layout Test, anyone could help me to create it?
Below are my testing pages:
<a href="test302Redirect.php#123456">Fragment ID for 3xx redirection</a><br/> <br/>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<p>Welcome here! Please check below url information:</p>
<p>This page was redirected from test302Redirect.php#123456.</p>
Created attachment 240409 [details]
Corrected coding style.
We actually came across this issue testing mobile browsing on our sites with iOS. Redirects that should have passed back to the original requested content actually ended up on the default home page as the original redirect information was dropped in transit.
Checked out revision 175807 and applied the fix as submitted by Horky and the problem is resolved in this scenario.