|Summary:||URL Redirect Loses Fragment|
|Product:||WebKit||Reporter:||Andrés Santiago Pérez-Bergquist <aspb>|
|Component:||Page Loading||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||ap, bdavidson, becky.conning+webkit-bugzilla, beidson, ccouzens, ddkilzer, fishd, hartman.wiki, ian, jberlin, julian.reschke, karens, kldavis4, matt.eglin, matt, mihai, mrowe, nlundqu, rakuco, restuta8, tgerlach, thierry.allardsaintalbin|
|Version:||528+ (Nightly build)|
|OS:||OS X 10.5|
Description Andrés Santiago Pérez-Bergquist 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://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).
Comment 1 Mark Rowe (bdash) 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 3 Alexey Proskuryakov 2009-02-26 10:52:09 PST
The URL is mentioned above, it's <http://test.confuego.org/57819#c13>.
Comment 4 Alexey Proskuryakov 2009-03-21 04:21:58 PDT
*** Bug 24701 has been marked as a duplicate of this bug. ***
Comment 5 Matt Good 2009-05-23 14:09:15 PDT
Created attachment 30621 [details] Keep the anchor from the last URL when encountering a server redirect
Comment 6 Matt Good 2009-05-23 14:23:47 PDT
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 Alexey Proskuryakov 2009-05-24 00:44:59 PDT
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 Alexey Proskuryakov 2009-08-16 18:58:04 PDT
*** Bug 28368 has been marked as a duplicate of this bug. ***
Comment 9 Kelly Davis 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 (126.96.36.199) both preserve the fragment identifier during redirects. Safari (4.0.4) and the latest nightly webkit do not.
Comment 10 Chris 2011-04-24 08:34:19 PDT
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 Brian Davidson 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 Brady Eidson 2012-02-25 11:32:14 PST
(In reply to comment #2) > <rdar://problem/6623841> The radar is actually <rdar://problem/3225447>
Comment 13 Nils Lundquist 2014-09-04 14:02:09 PDT
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.
Comment 14 Horky 2014-10-24 05:23:07 PDT
Created attachment 240405 [details] Fixing patch 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: http://stackoverflow.com/questions/2286402/url-fragment-and-302-redirects 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/> test302Redirect.php <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body> <?php header('Cache-Control:no-cache'); header('Location:test302Redirect_after.html'); echo "<h2>"; print gmdate("Y-m-d\TH:i:s\Z"); echo "</h2>"; ?> </body> </html> test302Redirect_after.html <html> <head> </head> <body> <p>Welcome here! Please check below url information:</p> <p>This page was redirected from test302Redirect.php#123456.</p> <strong><div id="url">BLANK</div></strong> <script> document.getElementById("url").innerHTML=location.href; </script> </body> </html>
Comment 15 Horky 2014-10-24 06:16:07 PDT
Created attachment 240409 [details] Fixing patch Corrected coding style.
Comment 16 Matt Eglin 2014-11-11 06:34:34 PST
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.
Comment 17 Anton Vynogradenko 2015-08-11 16:29:49 PDT
This issue still exists for Safari 8 in case of redirect from HTTPS to HTTP and vise-versa. You can go to https://www.bayden.com/test/redir/fragment/redir-1.asp#!/HereIsSomeInfo to reproduce it.
Comment 18 Brady Eidson 2015-08-11 22:29:14 PDT
(In reply to comment #17) > This issue still exists for Safari 8 in case of redirect from HTTPS to HTTP > and vise-versa. You can go to > https://www.bayden.com/test/redir/fragment/redir-1.asp#!/HereIsSomeInfo to > reproduce it. Wondering if you've had a chance to try the El Capitan public beta(s).
Comment 19 Derk-Jan Hartman 2015-09-01 05:16:00 PDT
Still a problem with Safari 9 on Yosemite
Comment 20 Alexey Proskuryakov 2015-09-01 10:02:16 PDT
Please test with El Capitan public beta. This is fixed in a system component below WebKit.
Comment 21 Derk-Jan Hartman 2015-09-01 16:22:48 PDT
https://phabricator.wikimedia.org/T110976#1594914 "Confirmed, this works fine for me in Safari 9.0 on OS X 10.11 beta."
Comment 22 Karens Grigorjancs 2016-02-02 02:01:37 PST
So far it does not work on ios devices or the latest Safari on 10.11.2. Any chance the solution will be published soon?
Comment 23 Alexey Proskuryakov 2016-02-04 10:26:20 PST
Karens, could you please file a new bug about that, with a test case? This bug has already been verified as fixed, so you are probably running into a subtly different case.
Comment 24 Becky Conning 2016-05-20 12:22:19 PDT
(In reply to comment #22) > So far it does not work on ios devices or the latest Safari on 10.11.2. > Any chance the solution will be published soon? Did you file a new bug? I'd love to see the ticket.