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

Re: Working Group Last Call: HTTP/2 revision

From: Greg Wilkins <gregw@webtide.com>
Date: Fri, 10 Sep 2021 10:25:29 +1000
Message-ID: <CAAPGdfEyD9U-7Hfq5VO1cgjX=kmriTvMuR4SvtOEUVctWK3sMQ@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Thomson <mt@lowentropy.net>
On Fri, 3 Sept 2021 at 15:58, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Sep 02, 2021 at 10:47:58AM -0700, Roy T. Fielding wrote:

That's why I really think that we need to solve this ambiguity around
the notion of "authority". In HTTP/1.1 Host definitely conveys such an
> authority. Once we can make it clear that there is AT MOST one authority
> in a request (possibly from multiple sources which must match),


For my implementation, we convert the request from both h1, h2 (and h3)
into a canonical form that we pass to the layer above, which may or may not
be an intermediary/proxy.   The layer doing the canonicalization has no
idea if it is an intermediary or not.   Thus I don't think we should have
language that makes :authority/host handling conditional on being an
intermediary or not - as that would require my canonical form to carry two
authorities and for the layer above to make a choice about which one it
used, depending on if it is a proxy or not.

So I definitely support language that indicates that there is "AT MOST one
authority"  that can be transported via a :authority and/or host header.

> > I would have written that as
> >
> >    A recipient MUST ignore the Host header field in a request
> >    that contains an :authority pseudo-header field. If an
> >    intermediary forwards such a request via HTTP/1.1 without
> >    changing the request target, the intermediary MUST send
> >    the :authority pseudo-header field value as the Host field
> >    in the forwarded request (replacing any existing Host field)
> >    to avoid potential vulnerabilities in HTTP routing.
> >
> > Is that something we should add now?
> I'd rather proceed differently then, we explain how to extract
> that authority info for the protocol itself without precluding
> anything about other protocols,

Exactly.   The proposed text is about how intermediaries should work, which
presupposes that both copies of the authority will be made available to the
code that is the intermediary.     I think the text achieves the goal, but
hints at a less than optimal implementation.

I'd much rather that we define how an impl determines THE authority and
then define how an intermediary can send THE authority in Host and/or
:authority headers.


PS.  Yes - I know I posted a proposal earlier that was based on defining
intermediary language.... but I like the emphasis suggested by Highlander
Willy that there can only be one!

Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
Received on Friday, 10 September 2021 00:25:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 10 September 2021 00:25:55 UTC