Bug 24175 – URL Redirect Loses Fragment

• Status: RESOLVED
• Resolution: INVALID
• Component: Page Loading

[Andrés Santiago Pérez-Bergquist]

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).

[Mark Rowe (bdash)]

Do you happen to have a URL that reproduces this behaviour that can be used for testing?

[Mark Rowe (bdash)]

<rdar://problem/6623841>

[Alexey Proskuryakov]

The URL is mentioned above, it's <http://test.confuego.org/57819#c13>.

[Alexey Proskuryakov]

*** Bug 24701 has been marked as a duplicate of this bug. ***

[Matt Good]

Created attachment 30621 [details]
Keep the anchor from the last URL when encountering a server redirect

[Matt Good]

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.

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

*** Bug 28368 has been marked as a duplicate of this bug. ***

[Kelly Davis]

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.

[Chris]

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

[Brian Davidson]

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

[Brady Eidson]

(In reply to comment #2)
> <rdar://problem/6623841>

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

[Nils Lundquist]

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.

[Horky]

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>

[Horky]

Created attachment 240409 [details]
Fixing patch

Corrected coding style.

[Matt Eglin]

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.

[Anton Vynogradenko]

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.

[Brady Eidson]

(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).

[Derk-Jan Hartman]

Still a problem with Safari 9 on Yosemite

[Alexey Proskuryakov]

Please test with El Capitan public beta. This is fixed in a system component below WebKit.

[Derk-Jan Hartman]

https://phabricator.wikimedia.org/T110976#1594914

"Confirmed, this works fine for me in Safari 9.0 on OS X 10.11 beta."

[Karens Grigorjancs]

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?

[Alexey Proskuryakov]

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.

[Becky Conning]

(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.

[Thomas Gerlach]

Maybe the BUG 158420 is a left-over of this issue.