Re: Host and :authority (was Re: Working Group Last Call: HTTP/2 revision)

> Am 08.09.2021 um 08:46 schrieb Willy Tarreau <w@1wt.eu>:
> 
> Hi Greg,
> 
> On Wed, Sep 08, 2021 at 08:44:04AM +1000, Greg Wilkins wrote:
>> Currently RFC7540 says:
>> 
>>      An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST
>>      create a Host header field if one is not present in a request by
>>      copying the value of the ":authority" pseudo-header field.
>> 
>> 
>> So that is kind of a loophole as it says that a proxy must use the
>> :authority only if a Host header is not present.
>> If a Host header is present, but has been ignored due to the presence of an
>> :authority header, then a proxy may decide to act based on the :authority,
>> but send a request using a host header with a differing value that it had
>> previously ignored.
> 
> Exactly.
> 
>> I think we can clarify this without making significant (any?) changes in
>> behavior. I'd expect that most implementations would not need to change as
>> they are likely to pass only a single value to the layer that does the
>> proxying, but it would be good if the spec could back them up by saying
>> that rewriting a host header is the correct thing to do when acting as an
>> intermediary converting to HTTP/1.   There may be some impls that decide to
>> proxy based on the :authority, but then just copy over a different existing
>> Host header, and I think such impls probably should change as that feels
>> like tunneling misinformation.
>> 
>> How about something like:
>> 
>> An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST include a
>> Host header field in a request, using the value of the ":authority"
>> pseudo-header field if available or the received Host header otherwise.
> 
> We really must stop speaking about HTTP/1.1 in the HTTP/2 spec. There's
> no way multi-protocol implementations are aware of what the other side
> will use. Sometimes you even receive an H2 request, try to pass it over
> H2 then fall back to H1 (due to ALPN for example), or various other
> situations. That's why we really must focus on translating bytes to
> semantics and use semantics only. Semantics govern how HTTP must be
> interpreted and what each field (or combination of) means. Messaging
> explains how to recover the elements from the wire representation. We
> must really stick to this otherwise we'll continue such mistakes that
> do have consequences.

+1

I heard also that there is yet another HTTP version in the works.

> But my question still holds: are we aware of any valid case for Host
> and :authority to mismatch ? I've enumerated a dozen of combinations
> earlier, none of which would result in this, and yet we're trying hard
> to make sure we can continue to forward attacks unmolested to the next
> hop. This is a real problem :-/

Not aware: that such requests are made against Apache httpd
Aware: that we flatten them an no one has complained.

FWIW, from our perspective, no mixed authority/host requests are
expected to work, other than given the response based on authority alone.

That is of course only a very limited sample.

Cheers,
Stefan

> 
> Regards,
> Willy
>

Received on Wednesday, 8 September 2021 08:04:27 UTC