Re: [Technical Errata Reported] RFC7540 (5249)

On 01/02/18 19:32, 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.

Ah, HTTP2-Settings is a connection specific header anyway.
Intermediaries are *required* to remove it when forwarding, by section
3.2.1 paragraph 4.

So removal seems to be a non-problem.

>> Maybe the right conclusion to draw
>> here is that you have to include at least one setting if you use this
>> header field.
> I just tried to see if "====" would be possible as an encoding for an
> empty string, but at least the base64 utility I have here considers
> that it's an invalid input, so I suspect that it's not widely accepted
> to have an end tag at the beginning of a base64 string. Thus most
> likely as you suggest, something needs to be sent. Maybe we should
> recommend to pass one of the default settings in this case.
> Willy

IMO, empty field-value should be valid even if it technically is not
now. It is semantically (and literally) equivalent to a SETTINGS frame
with 0-byte payload.

On the plus side it should be a no-brainer for implementations not to
even attempt decoding a 0-byte string.

(That said the Squid tools for now send a pre-computed blob with the
default SETTINGS from the spec. Have not tried sending empty payload.)


Received on Friday, 2 February 2018 10:38:39 UTC