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

[Jeff Pinner <[e-mail]>]

Julian, if you recall (or have easily accessible) I'd love to hear the
rational for the "ought to be handled as an error" line as opposed to a
"SHOULD return a 400" or "MUST return a 400."

Perhaps it is due to some subtlety that should lead us to reconsider the
2.0 requirement? Or perhaps it is due to legacy implementations and it
could guide us in wording to add to a HTTP/1.1 <--> HTTP/2.0 section?

- Jeff


On Wed, Jul 10, 2013 at 4:33 AM, Julian Reschke <[e-mail]>wrote:

> On 2013-07-09 22:59, Jeff Pinner wrote:
>
>> 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.
>> ...
>>
>
> My 2 cents: HTTPbis says what it says based on a long discussion of the
> topic. IMHO simply saying "should be aligned with whatever 2.0 says" is not
> sufficient to change that.
>
> Best regards, Julian
>