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

[Jeff Pinner <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>wrote:
>
>> On 9 July 2013 10:12, Michael Sweet <[e-mail]> 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
>
>