s/is/is not/. In IE, I can see this by simply hovering over each of latter two links, while FireFox tries to be "friendly" and hides the difference from me. But if you view the source, you will see:

<a href="http://en.wikipedia.org/wiki/Special:Search?search=Perl%23fut
+ure">
vs. <a href="http://en.wikipedia.org/wiki/Perl#Future">
[download]

And the important difference is not most of the difference there, just the difference between "%23" and "#".

The former of those only works because Wikipedia special-cases that search and redirects to a URL that includes the anchor that is part of the search terms in the URL that PerlMonks produces. And you can test the effect by going to Wikipedia and typing "perl#future" into the search box and submitting.

Of course, I proposed years ago that we make some clean-up to link parsing which includes making anchors work on most link types (since they work on almost none of them now). So I'd like to see the implementation of that proposal get finished (it was started but one of the gods disliked the idea and so I never finished debugging what I had written).

And a funny thing is that "fixing" this would actually break the second case. I wasn't sure, since the search of Wikipedia involves a redirect, when the anchor is included as an actual anchor, would the anchor be lost when the redirect happens. In IE, the anchor is lost. In FireFox, the anchor gets shown in the browser address bar after the redirect, but the anchor doesn't actually work (you end up at the top of the Perl page in either browser).

So, after fixing the general case (so that #blah gets emitted as an anchor while \#blah encodes the # to be part of the pre-anchor URL) we should special-case wp:// (then consider other cases like doc://$# vs doc://perlop#Shift-Operators).

The fragment identifier isn't supposed to be transmitted..

Whether the browser transmits it or not (I didn't test that, since it matters little here) doesn't impact whether the browser chooses to keep it around after the redirect nor whether it manages to actually keep it around in a useful manner. "Both browsers" ultimately fail.

But thanks for the term of art. I've previously looked for such and seen others look for such, all unsuccessfully. Though I had no problem finding it just now by searching for html rfc and then searching RFC 1866 for "#".

- tye