set HTTP_X_REWRITE_URL without Unmangle flag?

Topics: User Forum
Oct 31, 2006 at 7:47 PM
a user writes:

> I'm not into C-programming so can't fix/change it my self: is it an idea to always add the HTTPXREWRITE_URL to the headers? Now it will only be done when having the U modifier on. However it's sometimes usefull to use the original URL in my pages and it would be handy to get it from the headers. Because I need IIS logging on rewrited URL I can't use the U modifier.

the readme for IIRF says that when the U flag isattached to a rule, it
...tells the filter to store the original, unmodified URL
in the server variable called HTTPXSERVER_URL, and also tells
IIS to log the original, pre-rewrite URL in the IIS log file.

Essentially it sounds like this user wants to separate these two actions. He wants the server variable to be set, but he wants the post-rewritten URL to be logged in the IIS logfile.

Oct 31, 2006 at 7:49 PM
This should be pretty easy to implement I think.
It could possibly be either
- a new directive in the ini file (RewriteSetVar or something)
- a new per-rule flag. ( maybe S )

Is this feature important?
of the two options, what do people prefer?


Oct 31, 2006 at 8:00 PM
I don't know if it's important, but I don't see a need for a whole nother flag - just a command in the INI should be good enough - it can't hurt to have that header on all things.
Nov 2, 2006 at 1:52 PM
I think a new INI-file directive would be the ideal way to go. Also, a generic directive capable of adding, removing, and rewriting header variables (similar to ISAPIRewrite's RewriteHeader directive - ) would IMO be vastly more useful than a directive which simply allowed you to enable/disable the HTTPXSERVERURL header.

A "RewriteHeader" feature wouldn't be hugely useful to me immediately because I want to use the U Unmangle flag for everything. However, if I didn't, I would definitely want to make use of a "RewriteHeader" directive, or at the very least have some way to store the original URL in a header (like "A user" requested).

PS: In the v1.2.10 documentation (Readme-1.2.txt) it lists both HTTPXREWRITEURL (e.g. on line 411) and HTTPXSERVERURL (e.g. on line 537) as the header variable used to store the original, unmangled URL. I haven't actually used IIRF yet (though I'm hoping to switch to it from ISAPI_Rewrite soon) so I haven't tested this myself. Does the unmangled URL get stored in both headers, only one of the two, or am I missing something? Thanks, Cheeso!
Nov 3, 2006 at 12:37 AM
Good catch, Steve.

The correct server variable name is HTTP X REWRITE URL .
That bug in the readme has been corrected and will be available in the next drop.

Nov 3, 2006 at 12:40 AM
Steve, can you give me an example,
how would RewriteHeader be used to set the value in the server variable HTTP X REWRITE URL ?

Nov 5, 2006 at 7:56 PM
Well, the ISAPI Rewrite documentation gives the following example of how to create a new HTTP header using their product:

RewriteCond URL (.*)
RewriteHeader Old-URL: ^$ $1

(Example found here: )

I'd imagine that could translate into something like the following with IIRF:

RewriteCond %{HTTP URL} ^(.*)$
RewriteHeader Old-URL: ^$ %1 L

Or perhaps instead it could be done in one line with something like this:

RewriteHeader Old-URL: ^$ %{HTTP URL} L

That is, if you wanted to use only one directive (RewriteHeader) to rewrite, create, and delete headers. Of course, another route could be to use three discrete directives for the tasks.

Incidentally, have you considered moving the IIRF forum off of CodePlex? Since CodePlex seems to automatically attach formatting to uses of the underscore, asterisk, and square bracket characters (possibly among others), that seems very troublesome considering that regular expressions make heavy use of those characters, and also since underscores are used heavily in variable names.
Dec 17, 2006 at 7:14 PM

The "a user" here ;-).

I was wondering if you have any if this functionality will be available in a newer version, and if so, when this new version will be released.

It would be a great extra for me to an already great product.

Feb 24, 2007 at 2:01 AM
This discussion has been copied to Work Item 8464. You may wish to continue further discussion there.