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 13:59:08 -0700
Message-ID: <CA+pLO_jL63qxtFFvC=JN5iJSr2_B8KkBftX9K19M0x3qV7HOLw@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, list <ietf-http-wg@w3.org>
I am all for adding text to the "Additional HTTP
Requirements/Considerations" sections that discuss how to upgrade from
HTTP/1.1 to HTTP/2.0, including what to do about how to handle specific
headers, Expect and Content-Length / Transfer-Encoding included. This would
be useful not just to implementers migrating to HTTP/2.0 but also to
proxies that upgrade/downgrade the protocol version.

That being said, the requirements around Message Length in HTTP/1.1 are
non-trivial and given that we want to support interoperability, I'd like to
minimize adding additional requirements (especially those with conflicting
semantics) in the HTTP/2.0 spec.

P.S. the httpbis messaging draft states:

If a message is received with both a Transfer-Encoding and a
       Content-Length header field, the Transfer-Encoding overrides the
       Content-Length.  Such a message might indicate an attempt to
       perform request or response smuggling (bypass of security-related
       checks on message routing or content) and thus ought to be
       handled as an error.  A sender MUST remove the received Content-
       Length field prior to forwarding such a message downstream.

it would be nice to strengthen that language so that it matches the
new HTTP/2.0 requirement.

On Tue, Jul 9, 2013 at 1:45 PM, Michael Sweet <msweet@apple.com> wrote:

> Jeff,
> 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:59:35 UTC

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