Subject: Alt-Svc and HTTP Extensions

From: Lucas Pardue <[email-masked]>
Date: Wed, 16 Oct 2019 19:59:47 +0100

RFC 7838 frames a lot of discussion in terms of resource fetching, which is
supplied equivalently  by the core definitions of HTTP/2 and HTTP/3.
Therefore failure of an Alternative is discussed in terms of connection
errors or 421 (Misdirected Request) HTTP Status Code. But I'm starting to
wonder what expectations are for some classes of HTTP extension.

Lets assume a world where HTTP/2 and HTTP/3 co-exist but development and
deployment of extensions progresses at different rates. For example, right
now we may have HTTP/2 servers that support WebSocket (RFC 8441) but few
HTTP/3 servers that offer a similar extension (both because it is not
formally defined, and because it is not deployed on a fully authoritative
alternative).

A client that is happily using HTTP/2 WebSockets may see an Alt-Svc for
HTTP/3 and eventually decide to switch, only to find that it cannot do
HTTP/3 WebSockets. It could discover this early, because in this case the
extension is negotiated using SETTINGS_ENABLE_CONNECT. Howver, not all
extension require such a negotiation.

So the question is, was it correct or fair for the HTTP/2 server to
advertise the alternative that cannot satisfy the exact same desired
properties of the active connection? It seems like a class of error similar
to Misdirect Request, caused by accidental advertisement due to poor
coordination. However, extensions may not be bound to request/response, so
perhaps there might be some benefit in defining a new error code that
allows an endpoint to reset streams or close connections.

Lucas

---

From: Patrick McManus <[email-masked]>
Date: Wed, 16 Oct 2019 13:10:50 -0700

On Wed, Oct 16, 2019 at 12:03 PM Lucas Pardue <[email-masked]>
wrote:

This is a well explained predicate. thanks!

> properties of the active connection?
>

I would think if another service wasn't really an alternate for the scope
of the issued alt-svc then its probably a bug that would benefit from an
error code. alt-svc is not resource scoped after all. For most services,
however, this is a more narrow question than the exact same set of
properties.. extensions like origin or secondary certificates for example
might not be critical to still being an alternate for the scope of the
alt-svc.. websockets is a good example of something that would be a problem.

> It seems like a class of error similar to Misdirect Request, caused by
> accidental advertisement due to poor coordination. However, extensions may
> not be bound to request/response, so perhaps there might be some benefit in
> defining a new error code that allows an endpoint to reset streams or close
> connections.
>
> a new code makes sense to me.