Bug #1884

not replying 304 when needed (1.4.20, mod_compress)

Added by ethaniel almost 11 years ago. Updated almost 11 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


Client header:

GET /include/js/all.js?v1 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv: Gecko/2008120122 Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
If-Modified-Since: Sat, 31 Jan
@@2009 13:11:23 GMT
If-None-Match: "2951812591"
Cache-Control: max-age=0

Server replies with:

HTTP/1.1 200 OK
Vary: Accept-Encoding
Content-Encoding: gzip
Last-Modified: Sat, 31 Jan 2009 13:11:23 GMT
ETag: "2951812591"
Content-Type: text/javascript
Content-Length: 41218
Date: Sat, 31 Jan 2009 13:22:00 GMT
Server: NPWS - pwrd by

Etags and modification dates are the same, so I assume the server should reply with a 304, instead of a 200.
I use mod_compress without a cache directory.

This is a serious traffic problem.


Updated by ethaniel almost 11 years ago

small workaround - set cache-dir to /dev/null


Updated by nitrox almost 11 years ago

Not sure if "Cache-Control: max-age=0" might also be important here...


Updated by ethaniel almost 11 years ago

Well that's what firefox sends out.
Anyways, for the time being I switched to nginx. Not only it sends out the headers correctly, it even allows you to remove headers in specific cases (for example I needed to hide the Vary header, to fix the IE no-caching bug).


Updated by ethaniel almost 11 years ago

ethaniel wrote:

small workaround - set cache-dir to /dev/null

actually no, this didn't help. Instead it just completely turned off my gzipping.


Updated by stbuehler almost 11 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2384.

Also available in: Atom