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

From: Patrick McManus <[email-masked]>
Date: Wed, 01 Feb 2017 01:23:51 -0800

On Tue, Jan 31, 2017 at 10:06 PM, Mike Bishop <[email-masked]>
wrote:

> Should we mint new scheme(s) that allows direct reference to a resource
> served exclusively over HTTP/QUIC?

I think the answer here is still no for scheme - we don't want 2 different
urls for resources that are supposed to be interchangable (and then the
caching rules are impacted, etc..).

But something like an authenticated SRV is an obvious path to go down
eventually.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 Feb 2017 10:11:09 -0800

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 Feb 2017 10:16:35 -0800

Oh, and @LPardue:  RFC 2818 says in Section 2.3:

>  When HTTP/TLS is being run over a TCP/IP connection, the default port   is 443. This does not preclude HTTP/TLS from being run over another   transport. TLS only presumes a reliable connection-oriented data   stream.

RFC 7230 updates this by saying:

>    The "https" URI scheme is hereby defined for the purpose of minting   identifiers according to their association with the hierarchical   namespace governed by a potential HTTP origin server listening to a   given TCP port for TLS-secured connections ([RFC5246]).
>
>   All of the requirements listed above for the "http" scheme are also   requirements for the "https" scheme, except that TCP port 443 is the   default if the port subcomponent is empty or not given....

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 Feb 2017 10:19:16 -0800

Oh, and also in RFC 7230:

> Although HTTP is independent of the transport protocol, the "http"   scheme is specific to TCP-based services because the name delegation   process depends on TCP for establishing authority.  **An HTTP service   based on some other underlying connection protocol would presumably   be identified using a different URI scheme....**

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

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 01 Feb 2017 10:54:25 -0800

@MikeBishop thanks for these, really interesting food for thought

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

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Feb 2017 00:02:52 -0800

On Wed, Feb 1, 2017 at 7:11 PM, Mike Bishop <[email-masked]>
wrote:

> 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.
>
Alt-Svc does not contemplate scheme or origins - it deals with routing and
protocol. Alt-Svc cannot change something from http:// to https:// (or vice
versa) nor does it imply anything about whether the content of those urls
differs if only the scheme is different.

I would say HSTS does come closer to what you're describing - but not
quite. It does nicely illustrate the problem of determining equivalence
(sometimes they are, sometimes they aren't) and for me is a pretty good
reason to steer clear. Things white and black lists that https everywhere
needs to deal with are another example.

I think quic would be much better off if it could just stick to the https://
train.

what if we added some 'prior knowledge' language here ala h2?

> 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:
>
well, if they don't have a tcp stack, then they don't have to worry about
fallback.. so why not just try quic? I guess you don't know what versions
to try, but they are unlikely to be encoded in the scheme either..

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

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 02 Feb 2017 01:47:15 -0800

On 2 Feb 2017 8:02 a.m., "Patrick McManus" wrote:

But is that kind of behaviour prohibited by the sections of RFC 7230 that
Mike quoted?

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

---

From: Patrick McManus <[email-masked]>
Date: Thu, 02 Feb 2017 03:04:38 -0800

I'm thinking about this in terms of clients that don't have tcp support. If
we're really talking about origins that don't have tcp support instead,
then I think a new scheme makes more sense.

> But is that kind of behaviour prohibited by the sections of RFC 7230 that

I tihnk 7230 is defining what http and https schemes mean in terms of
namespaces and default reachability (which goes back to a origin does
indeed need to be able to publish a tcp version in order to use an https
scheme, but it don't require all accesses to happen that way)

This is sort of self evident even ignoring quic, we've already got alt-svc
changing routes and proxies obscuring DNS and addressing, caches which
don't need e2e transport at all , etc.. all of these things get data
identified by the same url via mechanisms that are bootstrapped (sometimes)
outside of the default interpretation..

I don't think a client that doesn't speak tcp is doing anything wrong by
just trying quic on an https url.. A more conservative reading of 7230
might indicate that QUIC for https:// even via alt-svc was non compliant
because it wasn't TCP and I don't think any of us believe that we need to
update 7230 to allow it.

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

---

From: hardie <[email-masked]>
Date: Thu, 02 Feb 2017 11:09:33 -0800

On Wed, Feb 1, 2017 at 10:19 AM, Mike Bishop <[email-masked]>
wrote:

> Although HTTP is independent of the transport protocol, the "http" scheme
> is specific to TCP-based services because the name delegation process
> depends on TCP for establishing authority. *An HTTP service based on some
> other underlying connection protocol would presumably be identified using a
> different URI scheme....*
>
> I read that as requiring a different scheme when the name delegation
process was different.  I don't see a different name delegation process as
probably for names served over QUIC (or least I don't see it as required).

If you dipped your toes into the "special use dns names" discussion, you'll
probably also remember that one of reasons TOR wanted .onion was so that
the signal that something should be resolved via TOR could be used within
the authority section of an HTTPS URL. That really did have a different
name delegation process for names below the .onion TLD, but that
consideration was ignored in favor of being able to pass "normal" (really
normal-looking) URLs around.

That experience hints to me that our minting a new scheme for this will
just be ignored in the common case, and I don't see a good reason to
generate the potential confusion as a result.

Just my take on it,

Ted

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/253#issuecomment-276736742>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABVb5CTcjjxL9mg74HKcICfQaXaWK2Gxks5rYMykgaJpZM4LzLA5>
> .
>

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

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 03 Feb 2017 03:41:25 -0800

In the non-conservative case, this seems to me somewhat of an implementation choice. For a client that wants to retrieve https://www.example.org/example.txt:

## Zero knowledge of hqm availability

- Client supports hqm and HTTPS in preference order. Race the hqm and HTTPS connections to the same host:
    - If hqm fails, use the HTTPS connection
       - If the HTTPS connection includes Alt-Svc for hqm on the same host, ignore it. The client already knows that hqm connectivity is not achievable.
       - If the HTTPS connection includes Alt-Svc for hqm on a different host, intelligently decide if its worth setting this up in the background for switch-over (e.g if the host resolves to the same IP, chances are hqm would fail again)
    ii. If hqm succeeds, tear-down the HTTPS connection

- Client supports hqm only. Tries to connect to host using hqm:
    - If hqm fails, tough luck
    - If hqm succeeds, happy days

## Prior knowledge of hqm availability via Alt-Svc
A client that has received Alt-Svc indicating hqm for an alternative that is still fresh:

- Client supports hqm and HTTPS in preference order. Tries to connect to the alternative using hqm:
    - If hqm fails, invoke Alt-Svc fall back (origin or alternates, hqm or HTTPS)
    - If hqm succeeds, happy days

- Client supports hqm only. Tries to connect to the alternative using hqm:
    - If hqm fails, invoke Alt-Svc fall back (origin or alternates, hqm)
    - If hqm succeeds, happy days

## Prior knowledge of hqm availability by other means
I.e. managed networks, whitelists etc

- Client supports hqm and HTTPS in preference order. Tries to connect to the host using hqm:
    - If hqm fails, depend on prior knowledge to determine if the host supports HTTPS (or always try HTTPS fallback)
    - If hqm succeeds, happy days

- Client supports hqm only. Tries to connect to the host using hqm:
    - If hqm fails, tough luck
    - If hqm succeeds, happy days

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 03 Feb 2017 15:29:51 -0800

@mcmanus, I'd agree that we don't need to update 7230 to allow QUIC.  The *authoritative* endpoint for an https origin is a TCP port, and Alt-Svc allows that authoritative endpoint to delegate to different endpoints -- other hosts, other ports, other protocols.  But the authoritative endpoint is always TCP to the port given in the URL.  That's why we're able to use the same scheme and avoid all the branching of stuff underneath it; the origin hasn't changed.

But when there's a service in which the authoritative endpoint is over QUIC -- a device-to-device REST API, or a device's configuration page -- then that requires a different way to express it.  I'd be fine with something like https://www.example.com:q443/, except that RFC 2396 restricts the port number to digits only.  (It's a little odd, in retrospect, that 2396 describes things in terms of IP and port, with no notion of ports being specific to their transport.)  @hardie is right that we're not defining a different name-delegation process here.

I'm leary of saying that clients should (or SHOULD, or even MAY) guess that an origin might be available elsewhere without a way to know that.  That's a proposition we rejec

Sure, we could put a checkbox in the UI or a parameter in the config file that says "'https' doesn't mean what you think it means," then couple that with "prior knowledge" language in the spec.  But it just seems *cleaner* to designate a scheme that's semantically equivalent to 'https' except that the ports in the URI are relative to a different transport protocol.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 06 Feb 2017 17:46:53 -0800

One example of such an "authoritative endpoint is over QUIC" is a QUIC proxy. That is to say, a semantically "HTTP proxy' which one speaks to via QUIC. Chrome today, for example, can be configured to speak QUIC to a proxy by using the "scheme" "quic" in the proxy.pac function.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 06 Feb 2017 20:12:23 -0800

Why don't you use ALTSVC at the proxy?  It's not like proxy setup is a commonplace action.  A new scheme isn't something one does lightly.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 07 Feb 2017 08:48:09 -0800

On Mon, Feb 6, 2017 at 8:12 PM, Martin Thomson <[email-masked]>
wrote:

> Why don't you use ALTSVC at the proxy? It's not like proxy setup is a
> commonplace action. A new scheme isn't something one does lightly.
>
> (Perhaps I used scheme in the wrong way?) We have support for "proxy",
"socks", "socks5" proxy schemes, so adding "quic" was quite straightforward
and is not user visible (though it is visible in the pac file, of course).
In any case, it's not clear to me that Alt-Svc applies to proxies. As I
read the spec, Alt-Svc defines a mechanism for an origin to specify a
different server. I don't think of a proxy as an origin, though I guess one
could? I'd be curious to hear more about this! That being said, in the
context of proxies it seems desirable for users to be able to deploy a QUIC
proxy without needing to also deploy an https proxy.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Feb 2017 15:57:23 -0800

An ALTSVC frame should work for the proxy if the intent was to move the proxy.  The ALTSVC frame is processed hop-by-hop.  I don't know how well that use case has been tested, but it should be possible to advertise an alternative for the proxy origin.

And as far as the proxy goes, don't you have to deploy a TCP variant for now and into the foreseeable future if you want to have it work?  It's just like any other service, I'd imagine, and the h2 server stack isn't that much extra to have.

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

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 07 Feb 2017 16:30:51 -0800

I thought we had a discussion about Alt-Svc plus proxies which concluded that Alt-Svc is not for finding proxies:

https://github.com/httpwg/http-extensions/issues/62

quoth mnot:

"Yeah. Alt-Sv is for finding an origin, not for finding a proxy -- a proxy might use it, though.
This should all be clear based upon reading of RFC7230, but if not we could add a sentence or two to clarify."

So I don't think Alt-Svc  applies here.

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 07 Feb 2017 16:40:26 -0800

Is the QUIC proxy in question actually HTTP/QUIC proxy, or a bit more like
a SOCKS proxy that would tunnel other protocols over QUIC?

On 8 Feb 2017 00:30, "Ryan Hamilton" <[email-masked]> wrote:

> httpwg/http-extensions#62
> <https://github.com/httpwg/http-extensions/issues/62>
>
> quoth mnot:
>
> You are receiving this because you were mentioned.
> <https://github.com/quicwg/base-drafts/issues/253#issuecomment-278190688>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AGRFtZZMp1cJhz7Zqv2ZEr0GyUwvjukNks5raQy7gaJpZM4LzLA5>
> .
>

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

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 07 Feb 2017 16:47:55 -0800

It's an "HTTP proxy" that the client speaks to via QUIC, I guess you could say. This is similar to the "https" proxy scheme that chrome supports when it wants to talk to an "HTTP proxy" over a TLS connection (which may result in an HTTP/2 connection to the proxy as the result of ALPN)

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 07 Feb 2017 17:04:24 -0800

Ah so I understand better that there's a slight dichotomy here. If a client
is configured to use an HTTPS proxy, and an origin advertises "hq" what
proxy should the client use? I don't think it's fair to assume that a
single proxy application has to support HTTPS and HTTP/QUIC.

If an HTTPS proxy were to offer an alt-svc itself that points to a
standalone HTTP/QUIC-only proxy, then does that upset things when the
client comes to try an access a new origin with a https scheme?

I think this is channeling some of McManus' earlier comments. If this is
repeating discussion of that old proxy thread then apologies, I'll do some
more background reading.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 07 Feb 2017 17:08:48 -0800

@LPardue, yeah, that's an old discussion.  A client makes a decision to use the proxy first, which results in ignoring Alt-Svc.  See RFC 7838.

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