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

[Mike Bishop <[e-mail]>]

We already have different URLs for things that might/might not be interchangeable.  When you use Alt-Svc between an http:// origin and an https:// endpoint, you're declaring that they're either interchangeable or you can properly process the distinction.

I can envision several scenarios where either server or client won't want to carry a full HTTP/TLS/TCP stack simply for bootstrapping, when they already know both peers will support HTTP/QUIC.  Maybe authenticated SRV is the path forward, but it seems like the simplest would be something like:

>    HTTP/QUIC is differentiated from HTTP and HTTPS URIs by using the 'httpq' protocol identifier in place of the 'http' or 'https' protocol identifier. An example URI specifying HTTP/QUIC is `httpq://www.example.com/~smith/home.html`.  Origins which serve the same content over HTTP/QUIC and HTTPS SHOULD provide an Alt-Svc header on the HTTPS endpoint declaring that the resource can be obtained over QUIC as well, and SHOULD NOT reference URIs with the 'httpq' scheme in responses to 'http' or 'https' requests.  Such origins MAY consider 'https' and 'httpq' to be equivalent while processing requests.

Note that I don't expect this to be used in browser-land anytime soon, if ever.  httpq:// would be inaccessible to legacy browsers, and you'd be cutting off a substantial portion of the web from following the link.  However, I think for non-browser scenarios and for testing, there should be a way to explicitly describe a QUIC endpoint.

-- 
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-276734604