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   ... View more

Hi,    Would you be able to provide a little more detail in what you are trying to do?     Is it that your JavaScript is adding Access-Control-Request-Headers to an OPTIONS request and you want vTM to add an  Access-Control-Allow-Headers containing that header to it's response?  i.e.   Browser--> OPTIONS (w/ header Access-Control-Request-Headers: X-Dummy) -->  vTM vTM --> RESPONSE  Access-Control-Allow-Headers:  X-Dummy   Not sure if that's what you had in mind but I tested doing the above and using the OPTIONS method on a VTM.  I was able to get vTM to take the value of the Access-Control-Request-Headers in a request and insert that into an Access-Control-Allow-Headers header in the response.  I used 2 rules to accomplish this, one Request rule and one Response rule:   Request rule:  check_CORS_header $cors_header = http.getHeader ( "Access-Control-Request-Headers" ); if ( $cors_header != "" ) { connection.data.set ( "CORS_Header_Exists" , $cors_header ); } ​ Reponse rule:  add_CORS_header $cors_header_to_add = connection.data.get ("CORS_Header_Exists"); if ( $cors_header_to_add != "" ){ http.setResponseHeader( "Access-Control-Allow-Headers", $cors_header_to_add ); } ​ I tested this using the Advanced Rest Client Chrome app and it seems to work, even when using the OPTIONS method:     Again, not sure if this is what you had in mind.  FYI the interesting piece is how you can use connection.data.set and connection.data.get to send information from a request rule to a response rule.   Cheers, Joe   ... View more