Re: RFC 9113 and :authority header field

[Kazuho Oku <[e-mail]>]

Thanks to Tatsuhiro and to all others for bringing the discussion.

2022年6月29日(水) 9:37 Martin Thomson <[e-mail]>:

> On Wed, Jun 29, 2022, at 09:58, Tatsuhiro Tsujikawa wrote:
> > I think 2) is valid in terms of RFC 7540, but it suddenly becomes
> > invalid in terms of RFC 9113?
> > Is this correct?  https://www.fastly.com and https://www.google.com now
> > reject 2).
>
> My understanding is that both are valid alternatives.  As would a third
> option that contained the same value in both host and :authority.  The 4xx
> responses you are getting are (probably) compliance bugs.
>

Are you suggesting that RFC 9113 has an error, or am I missing something? I
ask this because RFC 9113 section 8.3.1 states:
"Clients that generate HTTP/2 requests directly MUST use the ":authority"
pseudo-header field to convey authority information, unless there is no
authority information to convey (in which case it MUST NOT generate "
:authority")."
and
"An intermediary that forwards a request over HTTP/2 MUST construct an "
:authority" pseudo-header field using the authority information from the
control data of the original request, unless the original request's target
URI does not contain authority information (in which case it MUST NOT
generate ":authority")."

My interpretation of these MUSTs is that a client is forbidden to create a
HTTP/2 request that omits an `:authority` header field (unless the method
or the URI permits it to).


>
> Thankfully we know people who might be closer to someone who is able to
> fix or defend those bugs.  (On CC).
>
> This whole host and :authority thing was an original mistake in HTTP/2.
> It was grounded in the view that HTTP/2 had to faithfully capture every
> weird thing HTTP/1.1 could express, even when it didn't make sense.  At the
> time, that was pragmatic and it might have aided deployment into systems
> that were, on some levels, broken.  In time, we should seek to remove those
> exceptions.  In the revision, we did some of that by disallowing different
> values.
>


-- 
Kazuho Oku