Re: [Technical Errata Reported] RFC7540 (5249)

On 02/01/2018 07:32 AM, Willy Tarreau wrote:
> On Thu, Feb 01, 2018 at 12:43:53PM +1100, Martin Thomson wrote:
>> The observation is correct.  However, I'm not sure that this is the
>> solution I would choose.  I'm not sure, but I think that an empty
>> header field would cause problems.
> Some intermediaries risk to drop it, considering that empty is equivalent
> to absent.

I'm curious about this as I don't recall reading this in the RFCs. What 
is related to this is:

4.3  TE

    If the TE field-value is empty or if no TE field is present, the only
    acceptable transfer coding is chunked.  A message with no transfer
    coding is always acceptable.

This matches what you're saying.

5.4  Host

    If the authority component is missing or
    undefined for the target URI, then a client MUST send a Host header
    field with an empty field-value.

This seems contrary to what you're saying since the Host header is 
mandatory and dropping it would lead to errors further on.

RFC 7231 talks about empty Accept-Encoding and Allow headers where the 
value being empty has a different meaning than the header not being there.

RFC 7540 has no mention of empty headers except saying that :path must 
not be empty.

So my understanding is that intermediaries dropping empty header fields 
would be an error. Maybe dropping the empty TE header field would make 
sense but this isn't true of all headers.

Considering this I don't see why the HTTP2-Settings header can't be 
empty. Been working for me, at least.

Loïc Hoguin

Received on Friday, 2 February 2018 09:44:29 UTC