#1 304 response code not handled
I recently upgraded from mod_gzip-1.3.19a to
mod_gzip-1.3.26a. After upgrading my percentage of 304
(cached) repsonse code dropped dramatically; from
25-30% down to 2-3%. This morning I downgraded to
mod_gzip-1.3.19a. Here are the following stats:
Access Log for 11/13:
Total Requests: 1286797 (derived from wc -l
access_log.20021113)
304 Responses: 21592 (derived from grep "\" 304"
access_log.20021113 | wc -l)
% of Total: 1.68%
I downgraded the mod_gzip around 9:10 am ET. Here is a
running log of the stats over time:
11/14 9:10 am
total lines: ??
304 responses: 5417
11/14 9:19 am
total lines: ??
304 responses: 7620
Thu Nov 14 10:00:53 EST 2002
220649 access_log
17575
= 7.97%
Thu Nov 14 10:08:05 EST 2002
224542 access_log
19044
= 8.48%
Thu Nov 14 10:14:44 EST 2002
227984 access_log
20621
= 9.04%
Thu Nov 14 10:29:27 EST 2002
236148 access_log
23583
= 9.99%
As you can see as of 10:30 I have already exceeded the
previous day's 304 responses. Becuase the caching had
dropped off to such a degree I ended up using 2x as
much bandwidth so far this month as compared to last
month, with only a minimal increase in traffic.
Scott Geiger
Systems Information Manager
BC Media Group, LLC
Logged In: YES
user_id=649011
I forgot to add in my apache settings for mod_gzip. These
did not change from version; they were left the same for
each version:
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_minimum_file_size 300
mod_gzip_maximum_file_size 5000000
mod_gzip_maximum_inmem_size 100000
mod_gzip_keep_workfiles No
mod_gzip_temp_dir /dev/shm/gzip
mod_gzip_item_include file \.html$
mod_gzip_item_include file \.htm$
mod_gzip_item_include file \.shtml$
mod_gzip_item_include file \.jsp$
mod_gzip_item_include file \.php$
mod_gzip_item_include file \.php3$
mod_gzip_item_include file \.pl$
mod_gzip_item_include file \.cgi$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-httpd-php
mod_gzip_item_include mime ^httpd/unix-directory$
mod_gzip_item_include handler ^perl-script$
mod_gzip_item_include handler ^server-status$
mod_gzip_item_include handler ^server-info$
mod_gzip_item_exclude file \.css$
mod_gzip_item_exclude file \.js$
mod_gzip_item_exclude mime ^image/.*
Logged In: YES
user_id=329823
Since mod_gzip does *not* handle 304-queries, it seems not
to be a problem of mod_gzip but of the user agents. Perhaps
the cause is the Vary: header. You can turn it off (but you
shouldn't!) with 'mod_gzip_send_vary off'.
Logged In: YES
user_id=654872
I have noticed the same behaviour. I recently added the
folowing line to httpd.conf to force the exclusion of .gif to
increase the 304 rate for this files :
mod_gzip_item_exclude file \.gif$
Now there are much more 304 for this kind of files.
My whole mod_gzip configuration is :
mod_gzip_on Yes
mod_gzip_minimum_file_size 100
mod_gzip_maximum_file_size 0
mod_gzip_maximum_inmem_size 100000
mod_gzip_keep_workfiles No
mod_gzip_temp_dir /temp
mod_gzip_item_include file \.htm$
mod_gzip_item_include file \.html$
mod_gzip_item_include file \.jsp$
mod_gzip_item_include file \.srv$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^httpd/unix-directory$
mod_gzip_item_include file \.css$
mod_gzip_item_include file \.js$
mod_gzip_item_exclude file \.jpg$
mod_gzip_item_exclude file \.gif$
mod_gzip_item_exclude mime ^image/.*
mod_gzip_dechunk Yes
Logged In: YES
user_id=649011
Sorry I haven't gotten back to this sooner. I have been
working on other items and the old version of mod_gzip has
worked fine for me.
emmguyot:
adding the line: mod_gzip_item_exclude file \.gif$ is
redundant as you have: mod_gzip_item_exclude mime
^image/.* unless your .gif files are not of mime type image/.*
I do have the image/.* exclusion. This is only a partial fix as
it will exclude images only. What if you have a number of
static HTML pages? I don't want to re-serve them if the page
is already cached.
ckruse: I'll look into the VARY header, but as you stated I
shouldn't turn it off. My BASIC understanding of caching is
that the head information gets sent to the UA (consisting of
filename, size, date, etc). the UA then compares that
information to what it has on cache. What I am wondering is
if the gzipped "file" is either not sending the original filename
or if it's sending the current date/date of compression. So
then each file is a "new" file as far as the UA is concerned.
Scott
Logged In: YES
user_id=211909
It is not that mod_gzip doesn't handle 304 status codes.
Instead, your browsers misinterpret "Vary:" headers being
sent with everything that might be compressed.
The solution is to turn off mod_gzip for specific file
patterns, using the <Files> resp. <FilesMatch>configuration
directive of Apache.
http://www.schroepl.net/projekte/mod_gzip/cache.htm covers
this issue in more detail.