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),
>

+1

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.

cheers

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