- From: Lucas Pardue <lucaspardue.24.7@gmail.com>
- Date: Tue, 23 May 2023 15:20:51 +0100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CALGR9oY3jxNVGukqtK=ORYQ9bf4hGBMxqmbgq_CTY3f25Vz1vA@mail.gmail.com>
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 14:21:07 UTC