Query String matching in traffic script rule

[jgrunnell]

Hi - I'm a newcomer to Brocade VTM's and traffic scripts in general and wonder if someone can offer some help with a trafficscript thats not behaving as I would expect. I have a requirement to perform a 301 redirect on an URL such as:

Source:

http://www.example.com/path/?query=something-here#fragment

NOTE - there is a fragment identifier on the end of the query string.

Destination:

http://www.example.com/redirect/

A snippet from my trafficscript shows the workings of it.

..

$path = http.getPath();
$qs = http.getRawQueryString();

..

if ((string.startsWithI( $qs, "query=something-here#fragment")))
      {
    $myRedirect = $hostheader . "/redirect/";
         http.sendResponse( "301 Found", "text/html", "", "Location: http://" . $myRedirect );
      }
}

This results in you being sent to:

http://www.example.com/redirect/#fragment

So the redirect appears to work but it keeps putting #fragment on the end. I think this is because #fragment is not actually part of the query string itself.

Does anyone know how this can be handled or just stripped off the redirect?

Thanks in advance, Julian.

[Joe Poehls]

Hi Julian,

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:

https://blog.httpwatch.com/2011/03/01/6-things-you-should-know-about-fragment-urls/

https://www.w3.org/Protocols/HTTP/Fragment/draft-bos-http-redirect-00.txt

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.

Thanks,

Joe

[jgrunnell]

Thanks Joe - really appreciate your informative reply. So atleast I now know why this is happening and the options available to handle this type of request.

Thanks again - Julian.