- 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>
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. -Eric
Received on Tuesday, 15 April 2014 08:48:31 UTC