- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Fri, 14 Mar 2014 22:09:36 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Mark Nottingham <mnot@mnot.net>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> Unfortunately, the default web server in many cases is to serve .tar.gzip > files with Content-Encoding: gzip, at least last I checked. Yeah, and this was actually why I agreed with you throughout. In fact, right before I sent this new suggestion, I even wrote down what I thought is the consensus (I am pasting it again below). Reading this text, I became sad and sent in the new proposal above. ------------ 1. UAs must check hash against the representation (which is the message payload before content codings are applied, http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-3.1.1.5) 2. An exception is the case where the UA will save files to disk with the content encoding preserved, the developer needs to provide the hash on the gzip'ed file. -- Why I removed the encoding=gzip part for now: Having the encoding=gzip in markup brings up the issue of "well, what to do if it is not specified where we need it (.tar.gz download)? OR specified where we don't need it (e.g., images)? Or some completely different encoding (e.g., file is sent with gzip but encoding=sdch is set)?" All these issues will likely make the spec painful for browsers to implement and so maybe we are better off avoiding them (for now atleast) --------------------- The choice seems to be the spec above (or something similar) or what I believe is the much cleaner option of "Always remove content-encoding", where we ask developers to do a bit more work. I tested Google Code, SourceForge, and Dropbox and none of them seem to use Content-Encoding: gzip. (a random Apache server I tried did use Content-Encoding gzip). Like me, are you considering revising your opinion after reading the possible spec text above? thanks Dev
Received on Saturday, 15 March 2014 05:10:25 UTC