Re: [Technical Errata Reported] RFC7540 (5249)

On Fri, Feb 02, 2018 at 10:43:38AM +0100, Loïc Hoguin wrote:
> > 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:
(...)
> 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.
(...)

I know and that's what I'm doing as well when typing a request over
telnet and I don't know the host name (often you get a redirect with
the proper one by the way :-)).

I'm just saying that despite what is standard, I have already observed
a few intermediaries (abusively) dropping empty fields, so we must be
cautious about them. I've even seen this once with a CGI gateway which
would simply not pass empty fields as variables.

(...)
> So my understanding is that intermediaries dropping empty header fields
> would be an error.

I totally agree with you on this. I'm just warning you about some risks
in field based on some observations of this rare corner case which very
likely is not the most commonly tested.

> 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.

I would tend to think that H2 implementations being more modern, you take
less risks there than on older ones, but you're speaking here about an
upgrade where the header field passes over possibly old intermediaries.
That said, given that 101/Upgrade used not to work well before WebSocket
was specified, that could be another filter to ensure that you're limiting
yourself to reasonably modern devices anyway.

Cheers,
Willy

Received on Friday, 2 February 2018 14:08:29 UTC