| Change ID: |
48 |
Type: |
Bug |
| Title: |
wasted bandwidth |
Status: |
Closed (Fixed & Tested) |
| Severity: |
Trivial (e.g. Display Text) |
Version: |
Round 35 - Game |
|
Assigned To: Unassigned
[Add Response] | [Subscribe]
|
Planetarion Support Team Member
Will
|
| 30 Jul 2010 10:16 |
(I'll post this here too so I don't have to waste time typing it all out again next beta when it's still not fixed...)
I remember reporting this in another beta and nothing getting done... Last time I even provided a simple 3-line .htaccess fix that I've been using for years (it's at the bottom of this incase tl;dr).
When a static file is requested, Apache sends back Last-Modified and Etag headers. Browsers and other clients use these values in subsequent requests for the same file as a way of asking the server to only send the file if it has changed. If the file has not changed, the server should return a 304 Not Modified status header instead of the whole file and a 200 OK status.
Here's an example to make the problem clearer:
- I just requested /botfiles/alliance_listing.txt from the main game server. It returned 200 OK, a Last-Modified header of Wed, 28 Jul 2010 20:00:35 GMT, an Etag header of "43c009-ae9-48c7812219ec0"-gzip and the complete file. This was all expected.
- When I press F5 to get an updated version of the file, the browser sends an If-Modified-Since header of Wed, 28 Jul 2010 20:00:35 GMT and an If-None-Match header of "43c009-ae9-48c7812219ec0"-gzip in addition to everything it sent in the original request.
- The server returned exactly the same response as the original request. This should not have happened.
According to section 13.3.4 of RFC 2616 (the HTTP 1.1 spec),
" - If both an entity tag and a Last-Modified value have been
provided by the origin server, SHOULD use both validators in
cache-conditional requests.",
so the browser's behaviour here is correct.
Section 14.26 says, when the entity tag AND modification date match, "the server SHOULD
respond with a 304 (Not Modified) response, including the cache-
related header fields (particularly ETag) of one of the entities that
matched".
The reason Apache appears not to follow the RFC here is because the Etag doesn't match. The -gzip suffix added by mod_deflate makes the entity tag invalid.
Not fixing this causes unnecessary data transfer and wasted bandwidth, so here's what I use in .htaccess (as I said last time, please feel free to use this):
<IfModule mod_headers.c>
# Workaround for bug in mod_deflate where '-gzip' is appended to an outgoing Etag header but not
# removed from the incoming If-Not-Match header before Apache tests it against it's own value.
SetEnvIf Accept-Encoding gzip gzip-etag-bugfix
RequestHeader edit "If-None-Match" "^(.+)-gzip$" "$1" env=gzip-etag-bugfix
Header merge Vary Accept-Encoding
</IfModule> |
|
| Planetarion Support Team MemberWill |
| 12 Sep 2010 13:06 |
i suppose i should note here that this is no longer an issue on the new servers 
|
|
[Add Response] | [Subscribe]
|
