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

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

From: Jeff Pinner <jpinner@twitter.com>
Date: Tue, 9 Jul 2013 12:50:33 -0700
Message-ID: <CA+pLO_gzNTpTabeuXE7SE+J8Bnx7ky3bnxdKLxB5A-DiAS01Uw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Michael Sweet <msweet@apple.com>, "ietf-http-wg@w3.org list" <ietf-http-wg@w3.org>
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
>
>
Received on Tuesday, 9 July 2013 19:51:00 UTC

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