Forum Moderators: phranque

Message Too Old, No Replies

.htaccess - disabling logging

         

bluesting

8:23 am on May 18, 2006 (gmt 0)

10+ Year Member



Hi,

I have a .php script file that generates a dynamic gif/jpg/png image. AWStats (reading the Apache log files I presume) loggs all activity for this file under "pages" as if it's an html page someone accessed. This unfortunately leads to a higher unrealistic "pages" count. Is there a way to disable logging for this file (ideally I would have liked AWStats to log it's activity under images, but I doubt it's possible!).

Or any other viable solution would be appreciated! I have several .php pages now that also generate these dynamic images that I don't want to be logged as "pages" but rather as "images"!

Or, is it possible to rename the .php file to .gif and tell Apache to execute PHP on this file only, obviously I don't want PHP running on ALL my .gif files! This however is not the best solution, but could be used on one or two dynimic image scripts as some will output .gif only, while others are able to output ANY type of image, so a .gif extention would not be appropriate!

Kind Regards

jdMorgan

2:17 am on May 19, 2006 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



There are several solutions, some of which are restricted to server config level and others which are usable in .htaccess. If you have config-level access, then you can use SetEnvIf and mod_log_config to set up custom logging.

If not, then the answer depends on how your image requests get steered to the php script in the first place; If done correctly, the server should log those requests only as image requests in a simple setup, and this should be a non-problem. But I know nothing of your current implementation, and so can't comment further.

Jim

bluesting

6:35 am on May 19, 2006 (gmt 0)

10+ Year Member



Hi Jim,

I host the site on a shared server, so I don't have server/admin level permissions! The file I want to exclude is \image.php, in the root of my site! It generates a dynamic image with some parameters! My issue only really concerns the AWStats configuration, nothing more, I just want to get more accurate stats. AWStats thinks this file is a normal HTML page, not an "image" and logs it as such. On some pages, I could call this file upto 50 times to render various images. So one "page hit" will actually register as 51 page hits, thus unrealistically increasing my "page" counter.

I don't want to fiddle with the normal logging process or files, I just want to exclude this \image.php file from the logs. Or preferable somehow change the way AWStats logs this file in someway, for example make AWStats log the file as a GIF, maybe by changing the extention in the logs somehow! The file can output a GIF/JPEG or PNG depending on several input parameters. What the file is primarily used for is to dynamically resize images, so I store only the original image on the server and request various resized versions eg. Thumbnail versions etc.

Also, if that is not possible, could I change the extention to eg. \image.img and tell PHP to parse the file or that extention. I don't think AWStats will log the file as a "page" anymore with an extention of .img!

Also, I have another file, stars.php which ALWAYS outputs a GIF with special parameters, is it possible to change the filename to stars.gif and tell PHP to parse ONLY this GIF file, obviously I don't want PHP parsing/running on ALL GIF files, only this one!

Kind Regards

Romeo

7:41 am on May 19, 2006 (gmt 0)

10+ Year Member



There is a difference between 'logging' -- what the web server does in realtime, and 'statistics' -- which the AWstats does compute out of the web server's log information afterwards at a later stage.

I won't fiddle around with the logging. Instead, dig into the docs of AWstat to find a way to exclude certain records from getting counted into the statistics computation.

If you can't find that, there is another circumvention:
get the original log file and filter out these records by yourself before feeding the logfile to the AWstats program
`grep -v image.php original-log.file > filtered-log.file`

Kind regards,
R.

bluesting

8:18 am on May 19, 2006 (gmt 0)

10+ Year Member



Hi Romeo,

Sounds like a workable solution under certain conditions, however, the AWStats logs are generated "automatically" at midnight every night on this "Shared Server", there are probably hundreds of sites hosted on the same server! I don't think I'd be able to remove these entries from the logs everyday before AWStats parses the logs, and I don't think I have control over when and how the logs are parsed! I also don't think I have much control over the configuration of AWStats, because I'm guessing it's been automatically pre-configured by the control panel they use! When I try to access some sort of AWStats configuration file on the server I'm getting permission denied or "file locked or in use" type messages.

Stale mate for me! I'm still convinced that my best possible solution would be to eliminate or drop/remove the file from the Apache logging process, if it's possible to do in .htaccess!

The condition statements are in the form like:

if this condition is true then log the entry here, else log the entry somewhere else.

What I want to do is just say, continue with whatever logging is currently active unless the file is image.php, then don't log!

jdMorgan

6:41 pm on May 19, 2006 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



> If not, then the answer depends on how your image requests get steered to the php script

Let's clarify: When this dynamic image is requested, how is it requested? What does the <img> tag on the page loaded by the client (browser) look like? Or is the image even referenced from a page?

The exact access mechanism that is used by the client to request the image must be known before a good answer can be found.

The usual approach would be:

  • The page loaded by the client includes (links to) the image as <img src="URL_path_to_dynamic_image.gif">
  • Then mod_rewrite is used to intercept that image request, and steer it to the image.php script. The client would never know the iamge was generated by a script; It wouls see only a normal image reference.

    Example:


    RewriteRule ^dynamic_image\.gif$ /image.php [L]

    So... The URL is "dynamic_image.gif" and the actual handler filepath is "image.php"
    (Momentarily waxing philosophical, we illuminate the URL-filepath dichotomy.)

    In this case, the only thing visible in the raw server logs would be a request for the dynamic_image.gif URL, and it would be reported normally by your stats software.

    The point being, that rather than trying to put a band-aid on this, it might be better to go back to the start of the image loading process, and fix it so that no band-aid is needed.

    Jim

  • bluesting

    6:30 am on May 22, 2006 (gmt 0)

    10+ Year Member



    Hi Jim,

    I thank you guys for the advice!

    Yes, the images are loaded in an <img> tag similar to this

    <img src="/image.php?image=items/2/10/N6600GT_TD.jpg&max_width=128&max_height=96">

    This is an actual example taken from my site!

    The image will be re-sized to a maximum dimension of 128x96 ... maintaining it's perspective. So the image could be resized to something like 110x96 or 128x50.

    Anyway, there is only one minor problem with your solution Jim. That is, the script can accept ANY type of image format. Eg. .gif/.jpeg/.png etc.

    So if I rename it to .gif, it might not always be outputting gifs. The good thing is that the browsers don't decode the image file based on extention, but rather from the headers. So even if I rename it to .gif, I can still output .jpg image file content and the browsers won't stuff up!

    There is one major pitfall for me using this solution! I develop on an IIS server at home, but the host uses Apache. So I thought I'd learn and make use of some of Apache's wonderful features. I've installed Apache locally before, but removed it because it wasn't necessary to have Apache when IIS was installed anyway!

    My conclusion: I will likely use your suggestion, it's great! I might go so far as to make a rewrite rule for image.gif, image.jpg and image.png. So the extentions match the output, but then I'd have to check the file extentions of the image files everytime I want to use it.

    Anyways, thanks for the tips!

    PS: I'm trying to get as much PHP/Apache/Linux knowledge as possible before Vista comes out, I plan to move to a 100% Linux based solution soon!

    Kind Regards

    jdMorgan

    2:25 pm on May 23, 2006 (gmt 0)

    WebmasterWorld Senior Member 10+ Year Member



    See 'alternation' in your favorite regex reference:

    RewriteRule ^dynamic_image\.(gif¦jpe?g¦png)$ /image.php [L]

    Change the broken pipe "¦" characters to solid pipes before use; Posting here changes pipe characters.

    Jim

    bluesting

    2:52 pm on May 23, 2006 (gmt 0)

    10+ Year Member



    Hi Jim,

    Gotcha on that one! I LOVE Regular Expressions! And I LOVE the fact that MySQL has built in support for them!

    Anyways, thanks to this thread, I've moved 100% into Apache now! Installed it on my Windows PC at work and home. Was a real pain in the ass to setup on Windows! I mean, Apache is fine, got an installer, like next, next, next. Nothing to it, but to configure and setup PHP, additional modules/extentions. Then you've got a WHOLE new world of httpd.conf directives to learn. Restarted the service like 20 times etc.

    Anyway, that was the first time I ever managed to successfuly install it. The next installation at home went MUCH quicker! Now I know!

    Also, I've made my site 100% dependant on Apache now! IIS has nothing on mod_redirect! Made myself a PHP script that generates a new .htaccess based on several database queries etc. Kinda cool!

    Got a lot of lines looking like this now:

    RewriteRule ^intel/(.*) /$1 [L]
    RewriteRule ^intel$ /intel/ [R,L]

    Probably childs play to you! But it's a start!

    From a 700 byte .htaccess file to over 9kb, I've eliminated over 120 brand directories with the script and plenty of duplicate scripts etc.

    Anyway, thanks man!