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

Re: Porting T-E to HTTP/2: Reasons Against

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Tue, 15 Apr 2014 02:48:09 -0600
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <20140415024809.13ea4caa4a05b866d002cef4@bisonsystems.net>
Martin Thomson wrote:
> There's been a lot of email on this topic.  I want to just summarize
> the reasons for not doing this briefly and to reiterate that I don't
> think that this is a good plan.  We have, on a few occasions, opted
> for less than feature parity with HTTP/1.1, and I see this as a very
> good example of a feature we don't need.

Unless the consequence is intermediaries change C-E, thus diluting the
origin server's authority over its own resources. Content and transfer
codings are so *not* the same thing that this smacks of exceeding
HTTP2's scope by changing the semantics of the protocol, not deprecating
an "unused" feature. Matthew Kerwin also pointed this out; didn't think
I'd need to post the same point, but...

> 6. I haven't seen strong interest in implementing this from many
> people on this list, other than a few.  Many of these concerns are
> surmountable if a widely used implementation planned to implement the
> feature (think browser, OS, server stack).

I didn't realize quantity of support trumped even one person correctly
pointing out a serious design flaw, especially when it's been well-put
by a credible outfit like IAEA, plus Roy, and others. If that's what
you want, I guess I'll be back in a few minutes (so to speak), but not
before pointing out that these concerns become insurmountable if the
major implementers bork HTTP's semantics by failing to recognize valid
use-cases which expose said design flaw, instead dismissing them as the
edge-cases they likely are -- which doesn't make the problem go away.

Received on Tuesday, 15 April 2014 08:48:31 UTC

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