Re: h2 header field names

I’ve raised this as editorial - see <https://github.com/http2/http2-spec/issues/604>.

Thanks,


On 1 Sep 2014, at 5:37 am, Roy T. Fielding <fielding@gbiv.com> wrote:

> This comment is in reference to section 10.3 of
> 
> http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt
> 
>> 10.3.  Intermediary Encapsulation Attacks
>> 
>>   HTTP/2 header field names and values are encoded as sequences of
>>   octets with a length prefix.  This enables HTTP/2 to carry any string
>>   of octets as the name or value of a header field.  An intermediary
>>   that translates HTTP/2 requests or responses into HTTP/1.1 directly
>>   could permit the creation of corrupted HTTP/1.1 messages.  An
>>   attacker might exploit this behavior to cause the intermediary to
>>   create HTTP/1.1 messages with illegal header fields, extra header
>>   fields, or even new messages that are entirely falsified.
>> 
>>   Header field names or values that contain characters not permitted by
>>   HTTP/1.1, including carriage return (ASCII 0xd) or line feed (ASCII
>>   0xa) MUST NOT be translated verbatim by an intermediary, as
>>   stipulated in [RFC7230], Section 3.2.4.
>> 
>>   Translation from HTTP/1.x to HTTP/2 does not produce the same
>>   opportunity to an attacker.  Intermediaries that perform translation
>>   to HTTP/2 MUST remove any instances of the "obs-fold" production from
>>   header field values.
> 
> This section is incorrectly stated.  While it is worthwhile to warn
> implementors of the difference between header field name syntax,
> the actual sending of an HTTP/1.1 message is governed by HTTP/1.1
> (not this spec). The second paragraph is already forbidden by RFC7230,
> as is the third.
> 
> What this should say:
> 
> HTTP/2 allows header field names that are not valid header fields in
> the Internet Message Syntax used by HTTP/1.1 and cannot be registered
> as such with IANA.  An intermediary that is attempting to translate an
> HTTP/2 request or response containing such an invalid field name into
> an HTTP/1.1 message ought to ...
> 
>   {discard the field because only someone who wanted it to be discarded
>    would be stupid enough to use an invalid field-name} |
>   {do some magic undefined thing that has never been defined because
>    it is a stupid idea for any Internet protocol to suggest a change
>    to field name syntax} |
>   {send a STREAM_ERROR because they deserve it}.
> 
> Alternatively, restrict the HTTP/2 header name syntax (not including
> pseudo-headers) to the same syntax as HTTP/1.1, because that is the
> sane thing to do.
> 
> HTTP/2 allows header field values that are not valid header field values
> in the Internet Message Syntax used by HTTP/1.1.  An intermediary that
> is attempting to translate an HTTP/2 request or response containing such
> an invalid field name into an HTTP/1.1 message MUST perform the following
> encoding of the octets that are not allowed in field-content: {pick one}.
> 
> 
> Cheers,
> 
> Roy T. Fielding                     <http://roy.gbiv.com/>
> Senior Principal Scientist, Adobe   <http://www.adobe.com/>
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 3 September 2014 06:45:36 UTC