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

On Tue, 7 Sept 2021 at 18:32, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Sep 07, 2021 at 10:19:31AM +0200, Stefan Eissing wrote:
> > After living for 5 years with the current implementation, I am not sure
> I'd
> > like to change it.
>
> I can understand, however, when working as a proxy, what do you pass to the
> backend server ? I guess you're passing the only value you kept (i.e.
> :authority when present), not two possibly different values ?
>

 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.

I'd also be OK with making it just a SHOULD use the :authority if there is
a use-case for not doing so?

cheers


-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com