- From: Loïc Hoguin <essen@ninenines.eu>
- Date: Fri, 2 Feb 2018 10:43:38 +0100
- To: Willy Tarreau <w@1wt.eu>, Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Vasiliy Faronov <vfaronov@gmail.com>
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
https://ninenines.eu
Received on Friday, 2 February 2018 09:44:29 UTC