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

[Patrick McManus <[e-mail]>]

On Wed, Feb 1, 2017 at 7:11 PM, Mike Bishop <[e-mail]>
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