Bug #1884
closednot replying 304 when needed (1.4.20, mod_compress)
Description
Client header:
GET /include/js/all.js?v1 HTTP/1.1
Host: static.gallery.ru
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.9.0.5) 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 lighttpd.net
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 16 years ago
small workaround - set cache-dir to /dev/null
Updated by nitrox almost 16 years ago
Not sure if "Cache-Control: max-age=0" might also be important here...
Updated by ethaniel almost 16 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 16 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 16 years ago
- Status changed from New to Fixed
- % Done changed from 0 to 100
Applied in changeset r2384.
Also available in: Atom