Apr 28, 2010 at 7:00 PM

Cheeso, in after (?) should we be accessing the new REQUEST_URI header value in IIRF as:


or as:


I'm pretty sure it's latter (as that's how IIS treats custom headers), but I saw you refer to the first in another discussion.


Apr 29, 2010 at 6:44 AM
Edited Apr 29, 2010 at 6:48 AM

No - the former.


It's a pseudo-server variable.  Not a request header.  I mean to say, it's not a bona-fide server variable from IIS.  But when you reference it in IIRF conditions and replacement strings, IIRF will treat it just like a server variable, and will fill in the value as you expect.  If your applications that run on IIS behind IIRF (like wordpress or any php app, etc) try to reference REQUEST_URI, they will not find it.  That's what I mean by "pseudo-server variable."  It works only within IIRF.

You should be able to see these results pretty easily.

I've documented this in the v2.1.1.12 documentation, which is now available on the web.   If the doc isn't clear on this, let me know.

The [U] flag still works to set HTTP_X_REWRITE_URL, as a header.


Apr 29, 2010 at 2:55 PM

Ha, it wasn't in the docs yesterday when I looked ;-).

Anyway, that's not quite what I was expecting, but I can see how it's useful.  At least you don't have to build that variable yourself now for use in IIRF rules, but my immediate need was to use it in downstream applications.  However, as you say, IIRF still provides tools easy enough to provide that.

Once complication, what happens if I wanted to create and set the custom header "HTTP_REQUEST_URI" now?  For example:

RewriteHeader Request_URI:  ^$    %{REQUEST_URI}

Would that conflict with your pseudo-server var name?  Just checking, as that would seem to be a potential point of confusion.


Apr 29, 2010 at 4:26 PM

No conflict.  A header created that way would be available as HTTP_REQUEST_URI in downstream applications.

The reason this wasn't in the doc yesterday is because I just put it there!