Re: RFC 9113 and :authority header field

Hi Stefan,

On Wed, Jun 29, 2022 at 11:18:19AM +0200, Stefan Eissing wrote:
> MUST WORK:
> H2 :scheme: https, :path: /, Host: example.com
> H2 :authority: example.com, :scheme: https, :path: /, Host: example.com:443
> 
> SHOULD FAIL:
> H2 :authority: example.com, :scheme: https, :path: /, Host: badexample.com
>   if not, become H1 GET / HTTP/1.1, Host: example.com

Note authority, that would give:

    GET https://example.com/ HTTP/1.1, Host: badexample.com

which is invalid anyway and must fail. I'm not seeing a case that allows
:authority and Host to differ.

> MUST FAIL:
> H2 :scheme: https, :path: /
> 
> 
> Conversions:

I'm assuming you're talking about conversions by a gateway here, but
please correct me if I'm wrong.

> H1 GET / HTTP/1.1, Host: example.com
> -> H2 :authority: example.com, :scheme: <context>
>   -> H0 GET http://example.com/ HTTP/1.0
>   -> H1 GET / HTTP/1.1, Host: example.com

No, this one should not forge a :authority where there was not any,
it's the case that's covered by the "unless" rule in the spec, so
you'd get this:

  H1 GET / HTTP/1.1, Host: example.com
  -> H2 host: example.com, :scheme: <context>
    -> H0 GET / HTTP/1.0, Host: example.com
    -> H1 GET / HTTP/1.1, Host: example.com

> H1 GET http://example.com/ HTTP/1.1, Host: example.com
> -> H2 :authority: example.com, :scheme: http, Host: example.com
>   -> H0 GET http://example.com/ HTTP/1.0
>   -> H1 GET / HTTP/1.1, Host: example.com

Agreed.

> H1 GET http://example.com/ HTTP/1.0
> -> H2 :authority: example.com, :scheme: http
>   -> H0 GET http://example.com/ HTTP/1.0
>   -> H1 GET / HTTP/1.1, Host: example.com

Agreed, and the H2 form is the same as the most common one sent by
clients.

> H1 GET / HTTP/1.0
> -> H2 :authority: <context>, :scheme: <context>

Yep.

> H1 GET urn:ietf:std:97 HTTP/1.1, Host:
> -> H2 :authority: ???, :scheme: urn, :path: ???

I don't know either :-)

Cheers,
Willy

Received on Thursday, 30 June 2022 07:13:29 UTC