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

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Mar 2017 22:54:10 -0700

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

---

From: Erik Nygren <[email-masked]>
Date: Fri, 31 Mar 2017 08:56:49 -0700

What about extending the HTTP URI syntax in a way to give connection hints?
For example (very likely not the right syntax):

      https://www.example.com#svc=hq.443/

Where in the above example, the Origin (and thus host header and SNI) would come from the part before the "#".  On failure to connect, a TCP connect (ie without the hint) could also be used.  Cache entries would not include the part following the # as part of the cache key.

This is a variant of option 2, but with the difference that the Origin and object cache keys aren't impacted.  This is only appropriate for secured connections (eg, TLS / HTTPS).

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Mar 2017 09:19:49 -0700

We can't reasonably change the semantics of any of the fields of the URI: we have to assume that any valid field is in use and that an invalid field would trigger rejection.

(e.g., your example syntax would turn into `https://www.example.com` when passed to a client that didn't understand this.  Or, from another angle, that syntax is already a valid HTTPS URI with clear semantics.)

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