Subject: Re: [quicwg/base-drafts] Define "httpq" (#348)

From: janaiyengar <[email-masked]>
Date: Fri, 10 Mar 2017 12:31:04 -0800

Why would a browser access a dedicated service running over QUIC? I think this PR touches on something that's not gotten a lot of airtime yet -- that using QUIC without a fallback may not be a good idea for the public Internet, specifically since UDP reachability is not universal. This definitely needs discussion.

-- 
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/pull/348#issuecomment-285776694

---

From: ThomasSwindells <[email-masked]>
Date: Fri, 10 Mar 2017 14:04:49 -0800

Why (in the next 20 years) wouldn't a browser access a dedicated service running over QUIC as the first choice, hopefully by that time QUIC density will be such that every network does support UDP.

More concretely for the short term ALT-SVC isn't the only way to signal different ways to retrieve files. For instance DASH supports supplying multiple alternative base URLS within the manifest files, it would seem sensible to explicitly signal which servers can be used with httpq directly, otherwise all the benefits of 0RTT get lost. I don't think it is a reasonable assumption to assume that CDNs (or other large distributed systems) would necessarily be configured with all nodes supporting all services, it would be quite reasonable to deploy HTTP only and QUIC only nodes.

Another scenario a HTTPQ url would be sensible to support is when a QUIC service wants to generate a 302 redirect to cause the client to connect to a different node. The server can safely assume the client will be able to make another QUIC connection (particularly if the two server nodes are in the same network location). But when a client is presented with a redirect to a node it has never connected to it has no knowledge as to whether it should keep using HTTPQ or initially start with using HTTP. As I've already said I don't think it is a fair requirement to insist that all QUIC implementations must also be running an HTTP server.

-- 
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/pull/348#issuecomment-285797471

---

From: Leif Hedstrom <[email-masked]>
Date: Sat, 25 Mar 2017 10:38:48 -0700

Hmmm, not sure I'm buying this. Assuming QUIC wins, and becomes the future of HTTP, wouldn't UAs just switch behavior, such that we assume QUIC is the predominant protocol for https:// ? With an (optional?) fallback to HTTPS when needed (albeit slower)?

-- 
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/pull/348#issuecomment-289227155

---

From: ekr <[email-masked]>
Date: Thu, 30 Mar 2017 08:14:24 -0700

I'm not buying this either. Why would you want separate origins?

-- 
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/pull/348#issuecomment-290442767

---

From: ThomasSwindells <[email-masked]>
Date: Thu, 30 Mar 2017 10:53:12 -0700

If you are running a CDN then these aren't origins, they are delivery nodes. Potentially having some delivery nodes which don't support legacy HTTPS, or nodes which haven't yet been upgraded to support QUIC are both realistic circumstances.

-- 
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/pull/348#issuecomment-290489970

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 30 Mar 2017 11:05:30 -0700

Origin is defined to be the (scheme,host,port) of a URL. So if "httpq" is a
different scheme than "https", it's a different origin, by definition. If
we're merely talking about serving the same URL (https://) via both QUIC
and TLS, then we're not talking about a different scheme, merely an
alternative service (handled via the "hq" alpn token in an Alternative
Service advertisement.)

​Cheers,

Ryan​

On Thu, Mar 30, 2017 at 10:53 AM, ThomasSwindells <[email-masked]>
wrote:

> If you are running a CDN then these aren't origins, they are delivery
> nodes. Potentially having some delivery nodes which don't support legacy
> HTTPS, or nodes which haven't yet been upgraded to support QUIC are both
> realistic circumstances.
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/pull/348#issuecomment-290489970>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ASp6yhI3Nm8wXHez80rpM9Is9GlcrBwlks5rq-wIgaJpZM4MLoKT>
> .
>

-- 
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/pull/348#issuecomment-290494342

---

From: Patrick McManus <[email-masked]>
Date: Thu, 30 Mar 2017 11:22:04 -0700

+1 to ryan's comment - minting new schemes creates un-necessary pressure on
same-origin policies and create operational complexity.

that being said, I know Mike doesn't think this is a web scheme... but the
conversation seems to indicate it would invariably leak into (at least) the
discussion.

I'm opposed to a new scheme

On Thu, Mar 30, 2017 at 1:05 PM, Ryan Hamilton <[email-masked]>
wrote:

> > <https://github.com/notifications/unsubscribe-auth/
> ASp6yhI3Nm8wXHez80rpM9Is9GlcrBwlks5rq-wIgaJpZM4MLoKT>
> > .
>
> >
>
> —
> <https://github.com/quicwg/base-drafts/pull/348#issuecomment-290494342>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAP5s5IXOYzvmz-k9lXi80mOrW0v_n-Bks5rq-7pgaJpZM4MLoKT>
> .
>

-- 
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/pull/348#issuecomment-290500000