Shortened links with anchors lose anchor

[mzmcbride]

Clicking on https://bugzilla.wikimedia.org/64441#c2 lands me at https://bugzilla.wikimedia.org/show_bug.cgi?id=64441.

curl confirms:

$ curl -I "https://bugzilla.wikimedia.org/64441#c2"
HTTP/1.1 302 Found
Date: Mon, 28 Apr 2014 12:34:55 GMT
Server: Apache/2.2.22 (Ubuntu)
Location: https://bugzilla.wikimedia.org/show_bug.cgi?id=64441

Perhaps some browsers continue passing the anchor, but Apache isn't.

There may be a server-side flag that can be set for this. Otherwise, it may make sense to use the full URL.

[valhallasw]

Anchors are completely client-side; chrome requests https://bugzilla.wikimedia.org/64441 and follows the redirect, ending up at https://bugzilla.wikimedia.org/show_bug.cgi?id=64441. At that point, the browser tries to find the anchor on the page.

What browser are you using? As noted, Chrome on Windows works for me. IE11 too.

[mzmcbride]

Safari / OS X / 6.1.3 (8537.75.14)

I imagine Chrome / OS X behaves appropriately (i.e., retaining the anchor), but I also imagine that most clients do not.

[valhallasw]

Upstream bug: https://bugs.webkit.org/show_bug.cgi?id=24175

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

So: we can either tell people not to use Safari ;-), use the full URL, or maybe add a redirect on bugzilla, making

https://bugzilla.wikimedia.org/64441/c3

redirect to

https//bugzilla.wikimedia.org/show_bug.cgi?id=64441#c3

?

[mzmcbride]

Hmm, shit. I guess it is mostly upstream. Thanks for the WebKit link. :-) It was a helpful read and it also led me to http://www.w3.org/TR/cuap#uri.

Using the full URL wouldn't be terrible (an extra "show_bug.cgi?id=" per message and no redirection), but ... eh, it's probably fine to close this ticket.