Re: Does anyone actually use HTTP_1_1_REQUIRED or HTTP_VERSION_FALLBACK?

Hi Lucas,

On Tue, May 23, 2023 at 03:20:51PM +0100, Lucas Pardue 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.

I don't remember having noticed any. At least in haproxy we don't produce
them, and if we face them we'll just log a stream error (though in debug
mode we can see it precisely). Initially I naively thought that this was
designed to be used with WebSocket since initially it was not transportable
over H2, but I was wrong, since there was obviously no way for the client
to express such an intent that would have triggered such a message from
the server.

In short, not emitted, not seen.


Received on Tuesday, 23 May 2023 15:06:43 UTC