Forum Moderators: phranque

Message Too Old, No Replies

Log one file requests separately

Using setEnvif to filter where requests to specific files should be logged.

         

FrankTheDane

12:04 pm on Mar 8, 2006 (gmt 0)

10+ Year Member



I have this in my httpd.conf:

SetEnvIf Request_URI "^/count\.php$" special_log
CustomLog /home/web/logs/counter_access.log combined env=special_log
CustomLog /home/web/logs/access.log combined env=!special_log
ErrorLog /home/web/logs/error.log

This all works fine. Only now I have started to get faulty requests in
the log as well. So my question is this:
How do I write the SetEnvIf so that it checks for url parameters
like so:


SetEnvIf Request_URI "^/count\.php\?id=([0-9]+)\&$" special_log

If I put in this line the criterias are not met and all requests will
be logged in /home/web/logs/access.log

Any help would be greatly appreciated.
TIA Frank.

jdMorgan

3:55 pm on Mar 8, 2006 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Frank,

Welcome to WebmasterWorld!

Query string parameters won't appear in REQUEST_URI -- They are stored separately in QUERY_STRING instead.

Since your requirements are that both the URL and the attached query be a specific value, some combinatorial logic support is needed, so it might be easier to use mod_rewrite for this case, rather that mod_setenvif:


RewriteCond %{QUERY_STRING} ^id=([0-9]+)\&$
RewriteRule ^count\.php$ - [E=special_log:TRUE]

Because the special token "-" is used as the substitution URL, no URL rewriting will take place; Only the envar "special_log" will be affected (set to "True").

Jim

FrankTheDane

10:23 am on Mar 9, 2006 (gmt 0)

10+ Year Member



And thank you Jim for the quick reply.
I have been trying to implement your solution but to no effect.

I am using apache 2.0 with virtual hosts
and this is what I see in my log:

123.123.123.123 - - [09/Mar/2006:11:00:03 +0100] "GET /count.php?id=27" 200 336 "http://www.123.dk/toplist.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"
123.123.123.123 - - [09/Mar/2006:11:00:03 +0100] "GET /count.php?id=27&first=yes" 200 336 "http://www.123.dk/toplist.php" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)"

What I want is to get the second 'hit' logged specially because it has a second parameter on (here first=yes)

I tried both putting your solution in .htaccess file and httpd.conf file in the <VirtualHost *>.

I also tried adding RewriteEngine On.
And putting it all in <Directory /> both with / and full path.

Still all gets logged to the same logfile, namely:

CustomLog /home/web/logs/access.log combined env=!special_log

What am I doing wrong?

Again I really appreciate the help.

FrankTheDane

11:54 am on Mar 9, 2006 (gmt 0)

10+ Year Member



Helping another guy here in the forum I found the answer to my own question :)

I changed this line:


RewriteCond %{QUERY_STRING} ^id=([0-9]+)\&$

to this

RewriteCond %{QUERY_STRING} ^id=([0-9]+)\&.*$

and it all worked.

Thanks again Jim for leading me in the right direction.
And I am sure had I just given enough information about the problem you would have solved it for me the first time.
Thanks again.

jdMorgan

8:24 pm on Mar 9, 2006 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Just as an efficiency note:

RewriteCond %{QUERY_STRING} ^id=([0-9]+)\&

works just as well and saves CPU time.

".*" before "$" or after "^" is almost never needed -- And I mean practically never. The only exception is when its 'greediness' is used to prevent an ambiguity problem with an adjacent very-general subpattern. In almost all cases, a leading ^.* or trailing .*$ can simply be omitted, since the default regex behaviour will then be that it matches anything in that position if the pattern is un-anchored.

That code requires that at least one additional query parameter follow the "id=" name/value pair. If that's not the case, then just using


RewriteCond %{QUERY_STRING} ^id=([0-9]+)

will work better.

Jim

FrankTheDane

9:24 am on Mar 10, 2006 (gmt 0)

10+ Year Member



Ah, many thanks again Jim!
Its nice that know your regex are optimized rather than living with something you just hacked together.
I also updated my redirect script that you corrected in another threat. thanks a bunch.
Frank