Bug 24175

Summary: URL Redirect Loses Fragment
Product: WebKit Reporter: Andrés Santiago Pérez-Bergquist <aspb>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: ap, bdavidson, becky.conning+webkit-bugzilla, beidson, ccouzens, ddkilzer, fishd, hartman.wiki, ian, jberlin, julian.reschke, karens, kldavis4, matt.eglin, matt, mihaip, mrowe, nlundqu, rakuco, restuta8, tgerlach, thierry.allardsaintalbin
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   
See Also: https://bugs.webkit.org/show_bug.cgi?id=158420
Attachments:
Description Flags
Keep the anchor from the last URL when encountering a server redirect
none
Fixing patch
none
Fixing patch none

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://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 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 2 Mark Rowe (bdash) 2009-02-25 16:15:05 PST
<rdar://problem/6623841>
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 (4.0.249.49) 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.
Comment 25 Thomas Gerlach 2016-06-06 08:45:29 PDT
Maybe the BUG 158420 is a left-over of this issue.