User Name

Go Back   Planetarion Forums > vChange Tracker > wasted bandwidth

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

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

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]

All times are GMT +1. The time now is 01:23.

Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright 2002 - 2018