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

[Mike Bishop <[e-mail]>]

We've talked about four routes here:

1)  **Long live TCP.**  All HTTP sites will be dual-stack, and the authoritative endpoint will be TCP.  Clients MUST have a way to find the secure delegation from that TCP endpoint to QUIC, though we might define alternatives to Alt-Svc headers which could be done without TCP.  (Alt-Svc in DNS?)

2)  **Update RFC3986.**  RFC 3986 explicitly states that "The type of port designated by the port number (e.g., TCP, UDP, SCTP) is defined by the URI scheme."  We could update the URI to contain a protocol designator, whose default is defined by the URI scheme.  As it would be omitted in all existing URIs, their interpretation remains unchanged.  Then https://www.example.com:q443/ refers to QUIC on UDP 443.

3)  **Define a new scheme.**  See pull request.

4)  **What's it matter?**  Assume that HTTP/QUIC on port 443 is likely equivalent to HTTP/TCP on port 443 if the cert is valid and call it good.

We explicitly do not consider the same host on different ports equivalent authorities, even if they happen to be listening on both ports with the same cert.  Why is TCP 443 vs. UDP 443 any different from TCP 443 vs. TCP 444?  (4) seems like a security issue waiting to happen.

I'm going to reverse myself and disagree that (3) is undeployable on the web in the near-term.  App-to-app handoff on many (most?) platforms now uses custom URI schemes.  Apps that encounter unknown URI schemes ask the OS; the OS is able to invoke appropriately-registered apps or tell the user they need to get a capable app.  E.g. launching "nonsense://" produces this on Win10:

![image](https://cloud.githubusercontent.com/assets/4273797/24390519/18b217aa-134f-11e7-8c13-22a24805081b.png)

Some cursory testing shows that browsers block navigations to URI schemes that don't have an OS-registered handler.  But if you have two browsers, one QUIC-capable and one not, when you click an httpq:// link in the non-QUIC browser the OS will launch the QUIC-capable browser for you and you proceed on your merry way.  This seems almost exactly what we'd want to have happen.

(2) probably *is* undeployable, because legacy apps will attempt to parse the URI and declare it invalid.  They're semi-used to seeing unknown schemes (xboxliveapp-1297287741://, anyone?), but changes that break the parsers would be seriously painful.

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