This is a difficult case, in that the #fragment in an HTTP URL operates as a function of the browser rather than as data passed within the HTTP data transfer.
A couple of resouces that explain this:
i.e. fragment URLs will be stored in the browser, and if it is redirected to another site/location, after downloading the content there the browser itself tries to re-apply the fragment.
I tried your snippet out myself, and inserted log statements to capture what the vTM was seeing as the values for $hostheader, $qs, $myRedirect along the way, and the code works fine to match the URL including the #fragment. But when we try to redirect, no matter what you put in for the $myRedirect location string, the browser itself will add the #fragement on the end.
From the draft RFC above, it looks like this is the recommended behavior, and other resources indicate that most if not all modern browsers follow this recommendation. So it doesn't appear there is any way to delete out the #fragment part of the URL on a redirect.
Note the draft RFC does also say that:
If the client retrieves the resource using the new URI and the
resource turns out to be of a type that doesn't allow fragments to be
identified, then the client SHOULD silently ignore the fragment ID
and not issue an error message.
So even if the browser sends the #fragment, if the document retrieved after the redirect does not use it, the browser should ignore that and not display an error.
The draft RFC also says this, regarding when the browser should re-use the original fragment:
The exception is when a returned URI already has a fragment
identifier. In that case the original fragment identifier MUST NOT be
not added to it.
I also gave this a try by changing the redirect string to add a blank fragment at the end of it, like below:
$myRedirect = $hostheader . "/redirect/#" ;
This actually worked, it made the browser ignore/remove the original #fragment that I inserted, and change it to the blank fragment that was part of the redirect URL. So that may be an option for you.
Hope this helps.
... View more