Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

[Lucas Pardue <[e-mail]>]

I agree with the opinions about new scheme(s). However, it does seem a shame to have this implicit dependency on Alt-Svc delivered by HTTP. By my understanding of Alt-Svc, the origin would have the requirement of offering resources via HTTP(/TLS)/TCP in perpetuity. That seems a bit unfair to me.

I recall some talk about TCP fallback (e.g. at the QUIC BoF IETF 96). No text currently in WG docs seem to require this though. the closest is in the HTTP/QUIC mapping:

```
Connectivity problems (e.g. firewall blocking UDP) may result in QUIC connection
establishment failure, in which case the client should gracefully fall back to
HTTP/2.
```

If TCP fallback is not actually required, and a solution can be found to directly open QUIC connections then there is a route to deprecate HTTP(/TLS)/TCP. Similarly, constrained devices that want to operate without HTTP(/TLS)/TCP could do so, bearing the risk of %N connection failure rate.
----

Forgive this stupid question: is there text somewhere in an RFC that requires a client accessing resources with a `https` scheme to use TCP? I appreciate the scheme is described in terms of TCP and port 443 but wonder if  there is anything preventing a client from trying their luck on opening a QUIC connection whenever it sees a `https` scheme? ( a more sensible whitelist approach could also be taken). Perhaps this is more suited to an implementation debug feature, which supports Mike's testing ideas.

----

Forgive this other stupid question: what about other application-layer protocols over QUIC? Do they also have an implicit dependency on Alt-Svc, or is that totally inappropriate?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/253#issuecomment-276549420