- From: Valentin Gosu <valentin.gosu@gmail.com>
- Date: Tue, 23 May 2023 20:20:21 +0300
- To: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CACQYfiL5jEM9GafWKfse2eNyQ=axs=yTLdgBi1t1z77pKH635A@mail.gmail.com>
On Tue, 23 May 2023 at 19:13, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote: > Wow, thanks for all the replies folks. Didn't expect so many, so fast. > > One thing that stands out to me is that I didn't ask whether you > send/receive HTTP_1_1_REQUIRED in RST_STREAM or GOAWAY. > > If I'm reading correctly, Valentin's link into the Firefox source > indicates it's a special case for GOAWAY but not RST_STREAM. However, it > sounds like in the NTLM case at least it would be send in RST_STREAM? > There's also one for RST_STREAM <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http2Session.cpp#3284-3289> . Moreover, for NTLM we also have a special case when the response includes connection-based authentication header <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http2Compression.cpp#595-606> for which we also disable H2 <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http2Session.cpp#1555-1564> . > On Tue, May 23, 2023 at 4:49 PM Valentin Gosu <valentin.gosu@gmail.com> > wrote: > >> Hi Lucas, >> >> >> In Firefox we handle both HTTP_1_1_REQUIRED >> <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http2Session.cpp#2203-2205,2219-2221> >> and HTTP_VERSION_FALLBACK >> <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http3Session.cpp#1327,1331-1333> >> . >> >> For HTTP_1_1_REQUIRED we only have telemetry >> <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http2Session.cpp#248> >> for beta versions - but we've seen exactly 0 instances of this happening. >> >> Similarly for HTTP3 >> <https://searchfox.org/mozilla-central/rev/2d678a843ceab81e43f7ffb83212197dc10e944a/netwerk/protocol/http/Http3Session.cpp#2262> >> there are no records in telemetry of ever receiving HTTP_VERSION_FALLBACK >> from a server, even in release versions. >> >> >> Cheers, >> >> Valentin >> >> On Tue, 23 May 2023 at 17:24, Lucas Pardue <lucaspardue.24.7@gmail.com> >> wrote: >> >>> Hi all, >>> >>> HTTP/2 defines the error code HTTP_1_1_REQUIRED with the description >>> "The endpoint requires that HTTP/1.1 be used instead of HTTP/2.". The only >>> mention of this error code is in Section 9.2.1 that describes TLS 1.2 and >>> HTTP/2 and says >>> >>> > This effectively prevents the use of renegotiation in response to a >>> request for a specific protected resource. A future specification might >>> provide a way to support this use case. Alternatively, a server might use >>> an error (Section 5.4) of type HTTP_1_1_REQUIRED to request that the client >>> use a protocol that supports renegotiation. >>> >>> I was curious if anyone uses it this way. With the advent of TLS 1.3, I >>> presume an HTTP client wouldn't address this specific problem of >>> renogitation problem, so a client might need to do more complex logic. Or >>> it doesn't because nobody actually handles the situation as the RFC >>> describes it might happen. >>> >>> HTTP/3 defines the error HTTP_VERION_FALLBACK with the description "The >>> requested operation cannot be served over HTTP/3. The peer should retry >>> over HTTP/1.1.". There is no example of how this error code might be used. >>> >>> I thought I'd ask here to crowdsource some answers about whether these >>> codes are actually used in practice. >>> >>> In some circumstances, when dealing with a semantic or application >>> error, resetting a stream with an error code instead of serving an HTTP >>> response with an error status can be problematic. The circumstances under >>> which HTTP_1_1_REQUIRED or HTTP_VERSION_FALLBACK could feasibly happen seem >>> rather niche and might actually be alright. I'm trying to get a sense of >>> that. >>> >>> Cheers >>> Lucas >>> >>
Received on Tuesday, 23 May 2023 17:20:38 UTC