#1 304 response code not handled

open
nobody
None
2
2004-10-11
2002-11-14
Scott Geiger
No

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

Discussion

  • Scott Geiger
    Scott Geiger
    2002-11-14

    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'.

     
    • milestone: 248047 -->
    • status: open --> open-works-for-me
     
  • Emmanuel Guyot
    Emmanuel Guyot
    2002-11-22

    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

     
  • Scott Geiger
    Scott Geiger
    2003-04-29

    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.

     
    • status: open-works-for-me --> open
     
    • priority: 5 --> 2