W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: h2#404 requiring gzip and/or deflate

From: Roland Zink <roland@zinks.de>
Date: Tue, 01 Apr 2014 12:42:45 +0200
Message-ID: <533A9825.4050603@zinks.de>
To: ietf-http-wg@w3.org
On 31.03.2014 22:33, Patrick McManus wrote:
> Martin, I don't think you should take that as editorial as it 
> conflicts with some of the implicit-gzip use cases.
> CE gzip was made a fixed part of the protocol, in part, because 
> intercepting intermediaries (or antivirus libraries as a subset of 
> that) were explicitly stripping negotiation for it for their own 
> convenience. Making it non negotiable enhances the robustness of the 
> protocol against that which is imo the right trade given the history 
> here and the importance of compression.
> http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/
> http://stackoverflow.com/questions/2645883/accept-encoding-headers-being-sent-by-browser-but-not-received-by-server
There are also examples of proxies adding to the accept-encoding. Even 
when the accept-encoding isn't modified the proxy may compress the 
content. The Apache Trafficserver for example can do it.

Compression is important but does it work in all cases? If the proxy 
does content-encoding on behalf of the server then it creates a new 
entity. For example the Apache Trafficserver gzip plugin modifies the 
ETag if it isn't weak, see below. When HTTP/1.1 to HTTP/2 gateway could 
not opt out then it would have no choice than to create such an entity 
if the server uses content-encoding and the HTTP/1.1 client doesn't 
support it (or fail it). Such an entity is unknown to the server.

> On Mon, Mar 31, 2014 at 4:13 PM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>     On 31 March 2014 12:48,  <K.Morgan@iaea.org
>     <mailto:K.Morgan@iaea.org>> wrote:
>     > In rfc 2616, clients may opt out of the implicit "identity"
>     content-coding by sending "identity;q=0" (see section 14.3 rule #4
>     at https://tools.ietf.org/html/rfc2616#section-14.3)
>     I have no problem with that.  Unless I hear screams, I'll take your
>     proposed text.

//FIXME: the etag alteration isn't proper. it should modify the value 
inside quotes
//       specify a very header..
static TSReturnCode
gzip_etag_header(TSMBuffer bufp, TSMLoc hdr_loc)
   TSReturnCode ret = TS_SUCCESS;
   TSMLoc ce_loc;

   ce_loc = TSMimeHdrFieldFind(bufp, hdr_loc, TS_MIME_FIELD_ETAG, 

   if (ce_loc) {
     int changetag = 1;
     int strl;
     const char *strv = TSMimeHdrFieldValueStringGet(bufp, hdr_loc, 
ce_loc, -1, &strl);
     //do not alter weak etags.
     //FIXME: consider just making the etag weak for compressed content
     if (strl >= 2) {
       if ((strv[0] == 'w' || strv[0] == 'W') && strv[1] == '/') {
         changetag = 0;
       if (changetag) {
         ret = TSMimeHdrFieldValueAppend(bufp, hdr_loc, ce_loc, 0, 
"-df", 3);
     TSHandleMLocRelease(bufp, hdr_loc, ce_loc);

   if (ret != TS_SUCCESS) {
     error("cannot handle the %s header", TS_MIME_FIELD_ETAG);

   return ret;
Received on Tuesday, 1 April 2014 10:43:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC