W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: Comments on draft-ietf-httpbis-http2-04

From: Michael Sweet <msweet@apple.com>
Date: Tue, 09 Jul 2013 16:45:30 -0400
Cc: Martin Thomson <martin.thomson@gmail.com>, ietf-http-wg@w3.org, list <ietf-http-wg@w3.org>
Message-id: <A5F07EB0-894D-4D70-B3F1-925AF19AC573@apple.com>
To: Jeff Pinner <jpinner@twitter.com>

There is a long history of HTTP/1.1 servers that did not support Transfer-Encoding: chunked, and the PWG and others have spent a good 15 years harassing those (non-) implementors to get them to conform so we can do something other than print static files... :/

So whether or not we have MUSTs in the sentence, I think it is important to clearly identify the migration path from HTTP/1.1 chunking to HTTP/2.0 frames.  Making the jump from HTTP/1.1 to HTTP/2.0 will be a major effort for most vendors, and given past performance I'd like to avoid any ambiguous language that leads to implementation bugs and interoperability issues - it makes for some messy code when such mistakes are put in ROMs that can't be updated...

On Jul 9, 2013, at 3:50 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> I would prefer we say something to the effect of:
> If a server receives a request with a "Content-Length" header and
> the sum of the DATA frame payload lengths does not equal the value
> of the "content-length" header field, the server MUST return a 400 (Bad
> Request) error.
> and remove any other MUSTs and SHOULDs. By the way, I would like to note that this is different than how the HTTP/1.1 spec handles Tranfser-Encoding. From RFC2616 Sec 4.4:
> If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
> - Jeff
> On Tue, Jul 9, 2013 at 12:40 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 9 July 2013 10:12, Michael Sweet <msweet@apple.com> wrote:
> > I am uncomfortable with this wording primarily because a lot of POST usage
> > consists of streamed content - my particular interest is obviously printing,
> > but any streamed content will necessarily not be able to provide a
> > content-length header field. So instead I would suggest the following two
> > paragraphs instead:
> I think that your edits capture the spirit of what was intended by the
> existing text, with far less ambiguity.  Unless I get objections,
> those can be integrated.
> > My other comment is that I don't see any discussion of the Expect header,
> > nor do I see a issue on Github...
> There was a brief discussion at the last interim.  The feature is in
> serious jeopardy.  See #18:
> https://github.com/http2/http2-spec/issues/18

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 9 July 2013 20:46:01 UTC

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