W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2021

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

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 8 Sep 2021 08:46:04 +0200
To: Greg Wilkins <gregw@webtide.com>
Cc: Stefan Eissing <stefan.eissing@greenbytes.de>, Martin Thomson <mt@lowentropy.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20210908064604.GB14966@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.


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

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 :-/

Received on Wednesday, 8 September 2021 06:46:25 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 8 September 2021 06:46:27 UTC