We’re working with ebooks that are basically books and therefore in itself set, pretty static – once you cached them correctly they should not to be reloaded in your client much less your browser all the time because that would make your app slow and your mobile flat even slower – let alone the Java script sent with it is 40kB each single attempt. Now with epubs even more so: once you rendered them correctly, the text flows clear and e.g. a page turn shall not course a reload while nothing was modified – if nothing was modified. But since we’re using epubs to finally enable ppl to work with text in many different ways, we had to teach the clients the difference:
If you have not set annotations or bookmarks, links or embedments in the ebook you are working with in our reader, the client asks the server: “Look at that entity tag, anything changed since I last loaded this file?” and the server matches that specific code with his own current code of the file. If the ETags match, a 304 Not Modified Response is returned – that’s some hard math for the server, sure, but it reduces your server side sending process and saves you a lot of GB.
Simply put: Entity tags (ETags) are a mechanism to check for a newer version of a cached file. Which would be the ebook in our case, and the trick is to find out, where they make sense to save users band width while leaving the server in peace as often as possible to not slow it down. With ETags you tell the client when to talk to the server and what to do, if nothing changed. Right, nothing.
The other way around works for static content: Once you removed the ETag header, you forbid caches and browsers/clients to validate files, so they are forced to rely on your set of Cache-Control and Expires header. Basically you’ll have to delete If-Modified-Since and If-None-Match requests and their 304 response – if there is no question remaining, no answer is expected. This will lead to multiple scenarios of non-completition but gain speed.
That’s what en ETag request looks like that takes 12195 bytes for that one pic and could be reduced when remove ETag and not send back 304 (you remember: no question, no answer)
Response for /i/yahoo.gif
Later, if the browser has to validate a component, it uses the If-None-Match header to pass the ETag back to the origin server. If the ETags match, a 304 status code is returned reducing the response by 12195 bytes for this example. Great.
Apparently this does not run for IE 7 – but who’d have expected?
Thank you for your help, ppl @askapache.com

