On 21 June 2014 07:26, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2014-06-20 23:19, Martin Thomson wrote: > >> On 20 June 2014 14:08, Johnny Graettinger <jgraettinger@chromium.org> >> wrote: >> >>> We just (two weeks ago) killed implicit gzip in HTTP/2, so we're pretty >>>> sure it's a serious problem. >>>> >>> >>> >>> My recollection (and that of the meeting minutes) was that we killed >>> implicit gzip because there are gnarly HTTP/1 spec conformance issues, >>> and a >>> similar outcome can be achieved if first-mover HTTP/2 deployments refuse >>> HTTP/2 requests with a-e: identity. I don't recall it being >>> substantiated as >>> a "serious problem" in that conversation. >>> >> >> We killed it so that we could avoid having to talk about it any more. >> That worked out well, didn't it? >> > > Absolutely. > > Not having implicit GZIP seems to be undesirable performance-wise. Having > it is undesirable because of broken HTTP semantics. > > Time to finally fix T-E? > > Yes please! Every time it comes up there's a big outcry of "but nobody uses it!"... which is disheartening because the cry comes from the very people who _could_ be using it. C.f. <https://issues.apache.org/bugzilla/show_bug.cgi?id=52860> Although Roy's been trying to convince Apache for quite a while, it seems... 2009: "The best solution is to implement transfer-encoding as an http protocol filter module." <https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31> 2006: "The best solution is to not mess with content-encoding at all, which gets us out of both this consistency problem and related problems with the entity-header fields (content-md5, signatures, etc.). That is why transfer encoding was invented in the first place." < http://mail-archives.apache.org/mod_mbox/httpd-dev/200612.mbox/%3CB2A9B2B3-D938-4C7D-8434-B9FC00A120D3@gbiv.com%3E > -- Matthew Kerwin http://matthew.kerwin.net.au/
Received on Saturday, 21 June 2014 01:00:19 UTC