Strips #target from url

Ahh so 'node/123#target' is redirecting but losing the #target... interesting problem.

I'll have to investigate this. I'm not 100% sure that PHP can see that part of the URL...

Unfortunately, the fragment does not get passed to scripting languages like PHP.

However, SOME browsers preserve it for you - for example Firefox 2 (on the Mac at least). Safari 3.1 (on my mac), however, does NOT preserve the fragment.

In any case, as the URL passed to PHP cannot contain the fragment then there is not a lot we can do.

I can see how this could be a problem - for example, if you had a big site and had lots of links in articles encoded to 'node/123#comments' for the comment form. If you enabled the path module then all the links would break - but not in Firefox 2 ;-)

Sorry - not a lot can be done here (unless you can find a way to get the fragment from a PHP script)

AFAIK the #xyz is not even sent to the server, so there is probably nothing that can be done, the browser has to take care of that...

Yeah, the server should not even see the # part.
but,
What HTTP code is sent for the redirect?
I'm thinking that some of the redirects should be totally transparent to the browser - that is - the browser should remember to add the #anchor on to wherever it lands.
(I've not used global redirect, but think that some tweaking should get the browsers to behave as they should)

GlobalRedirect sends a 301 (using drupal_goto and telling it to use a 301 header).

Here is an example test...
http://www.thingy-ma-jig.co.uk/node/171#comment-2940

As I said earlier, in Firefox 2.0 on the Mac, the fragment gets preserved. Safari 3.1 (for OSX (Leopard)), fragment gets lost.

Running IE 7 in VMWare, fragment gets lost. IE6 (from MultipleIE) - fragment gets lost. Opera 9.26 for Windows - fragment is KEPT.

I've not really got any other (worthwhile) browsers to test this with...

So it seems that of the "major" browsers, only Firefox 2.0 (2.0.0.12 to be precise) and Opera 9 (9.26 to be precise) actually bother to preserve the fragment on a redirect...

The question is... Should they?

If you were to be redirected from
http://www.thingy-ma-jig.co.uk/node/171#comment-2940
to
http://www.thingy-ma-jig.co.uk/blog/17-03-2008/every-blog-needs-a-facebo...

... You'd probably WANT the fragment preserved - however the actual header wont mention it. The header issued will only tell it to redirect the main URL (and any queries).

So is the general consensus that this part of a redirect should be part of browser functionality?

Some quick tests:

I found that FF2 behaved perfectly with a
307 "Temporary Redirect",
303 "See Other"
301 "Moved Permanantly"
- carrying the anchor forward,
- moving to the place on the page,
- and displaying the rewritten location in the address bar.

with
307 "Temporary Redirect",
303 "See Other"
IE6
- jumped correctly to the anchored spot on the redirected page,
- but didn't show the anchor in the location bar. Although it displayed the new location URL.
BUT
with 301 "Moved Permanantly"
IE6
- DID show the anchor in the location bar ... actually it showed the original URL+Anchor making the redirect transparent
- Showed the target page
- but DIDN'T use the anchor to scroll down it.

Go figure.
Yes, it's the browsers job (has to be). I think they should respect extra URL parameters on the new target. I'm pretty sure you'd expect POST or GET parameters to be sent to the new destination also if you got a redirect. It follows the #anchor would be equally as valid.

Anyway. You may find a 307 gives you the expected results.

Unfortunately, 307 is 'Temporary' redirect... whereas we really want to use 301 (permanent).

Thanks for that testing though. Interesting behavior by IE6! I dont recall it doing that on my VMWare install...

Indeed, HTML #fragments are not parsed by the server. They are client-side only. You can deal w/them in javascript, but apache doesn't even log these things.