- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Mon, 4 Jul 2022 10:42:27 +0900
- To: Martin Thomson <mt@lowentropy.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Ian Swett <ianswett@google.com>
- Message-ID: <CANatvzy5S7+T9VPGehT72de+xz7C+MpSKpMATmxhfYXymg6e4A@mail.gmail.com>
2022年7月4日(月) 10:06 Kazuho Oku <kazuhooku@gmail.com>: > Thanks to Tatsuhiro and to all others for bringing the discussion. > > 2022年6月29日(水) 9:37 Martin Thomson <mt@lowentropy.net>: > >> 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")." > Regarding this MUST, it seems that we (maybe unintentionally?) tightened the language in https://github.com/httpwg/http2-spec/pull/961. It changed a generic "SHOULD" to a "MUST unless." > 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")." > This MUST seems to come from https://github.com/httpwg/http2-spec/pull/845/files. As of #845, we mandate intermediaries forward origin-form requests (e.g., a "GET / HTTP/1.1" + Host) using an `:authority` request header field. Maybe these changes have been unintentional. Regarding H2O, we did not intend to enforce the use of `:authority` pseudo header field, so I have no problem in reverting the behavior. But nevertheless, I think it's worth discussing the state of the specification. > > 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 > -- Kazuho Oku
Received on Monday, 4 July 2022 01:42:52 UTC