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

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
>
>