Re: A proposal

This proposal doesn't change that assumption.  It just says that if you see
http:// that means http/1.x. If you see https, that means TLS with either
http/1.x or 2.0. You only get plain text http/2 if you use the new scheme.
That ought to sufficiently make plain text http/2 largely undependable on
the broader Web,  while still allowing those who really want it a means of
doing so.

If someone wants to use a response header or DNS or whatever to advertise
that they support plaintext http/2, then they may do so.  But that's an
orthogonal issue.
 On Nov 17, 2013 12:45 PM, "Tim Bray" <tbray@textuality.com> wrote:

> Yeah, Mike’s right; the proposal is architecturally cool, I like it; but
> the universe of Web content is completely permeated with hardcoded “http://”
> and “https://” (static files, code, and templates) and I think we have to
> live with that :(
>
>
> On Sun, Nov 17, 2013 at 12:32 PM, Mike Belshe <mike@belshe.com> wrote:
>
>> I think I replied earlier, but I am strongly against any proposal which
>> introduces new URL scheme for HTTP.
>>
>> This is changing the UI of the web, which most users don't understand
>> (and shouldn't need to).  Right now, users don't have to know about HTTP2
>> vs HTTP1.1 vs HTTP1.  If we make them have to differentiate, we've really
>> screwed up badly.
>>
>> This would also open a new set of security risks, as you'd now have to
>> deal with sites that include resources from http: and http2:, and is that a
>> mixed-content warning?  I think it would have to be.
>>
>> Finally, this would make server side deployment very hard - there are a
>> tremendous number of applications (php, java, etc) with 'http://' hard
>> coded, and all of those would have to change.
>>
>> Mike
>>
>>
>>
>>
>>
>> On Sun, Nov 17, 2013 at 12:15 PM, Zhong Yu <zhong.j.yu@gmail.com> wrote:
>>
>>> If a URL is http://something, it better means that the document can be
>>> retrieved by HTTP/1 on clear TCP. If that assumption is broken, a lot
>>> of software will be broken.
>>>
>>> On Sun, Nov 17, 2013 at 1:58 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
>>> wrote:
>>> > In message <
>>> CACuKZqE4DDsZif_WA+fguDFXEJwHbVUKt6FdC-2CMqR5dWgiHA@mail.gmail.com>
>>> > , Zhong Yu writes:
>>> >
>>> >>As a web page author, how do I choose which scheme, http:// or
>>> >>http2://, to use for a link? Do I need to detect the browser version
>>> >>the page is rendered on?
>>> >
>>> > Right now we have two schemes in common use:  "http" and "https"
>>> > and people in both ends of the HTTP connection interpret that
>>> > (more or less) as "without privacy" and "with privacy" respectively.
>>> >
>>> > This is counter to the IETFs ratified semantics of the scheme as
>>> > protocol selector for these two values, but I think we will shoot
>>> > ourselves big holes in the feet, if we try to press the IETF
>>> > view down over everybodys head, as a preconditition for using HTTP2.
>>> >
>>> > The choice of HTTP/1 vs. HTTP/2 should be decoupled from the HTML
>>> > and from the browsers URL field, and therefore I cannot support
>>> > James proposal.
>>> >
>>> > My counter proposal:
>>> >
>>> > 1. HTTP/2 on port 100 is always plaintext, which makes life easy
>>> >    for network people and is conceptually simple for everybody
>>> >    to understand.  It also does not need any RTT before HTTP/2
>>> >    performance benefits kick in.
>>> >
>>> > 2. Encrypted HTTP/2 will go over 443 (if SSL/TLS is used, otherwise
>>> >    I suspect that will need a new port too ?)  This makes life
>>> >    easy and is conceptually easy to understand too.
>>> >
>>> > 3. Servers or intermediaries which can do HTTP/2 (port 100 and/or
>>> >    443) can indicate this two ways:
>>> >
>>> >    a) By sending a header in only the *first* HTTP/1 response on
>>> >       any connection.
>>> >
>>> >       This new header must be listed in "Connection:" since protocols
>>> >       supported is by nature a hop-by-hop property.
>>> >
>>> >       (For further study:  Make this a general purpose header which
>>> >       can also indicate HTTPS, SCTP or other protols supported ?)
>>> >
>>> >    b) In DNS records. (For futher study:  How ?)
>>> >
>>> >    Servers should do both. Intermediaries can only do a).
>>> >
>>> > 4. URIs in HTML documents do not change.
>>> >
>>> >         "http:" means "no privacy needed"
>>> >         "https:" means "privacy required"
>>> >
>>> >    The user-agent gets to resolve that into HTTP/1 and HTTP/2 (or
>>> >    any other protocols), according to policy, preference and custom,
>>> >    based on server provided information, possibly cached.
>>> >
>>> > 5. Upgrading a HTTP/1 connection on port 80 to HTTP/2 will not
>>> >    be supported, the risk of reducing web relibility is too high and
>>> >    it would add RTT costs before HTTP/2 performance benefits kick in.
>>> >
>>> > 6. Upgrading a HTTP/1 connection on port 443 to HTTP/2 is desired
>>> >    only if HTTP/2 cannot be a negotiated option during the TLS -
>>> >    handshake.  I don't know the answer to this one, it may for
>>> >    further study ?
>>> >
>>> > --
>>> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>>> > phk@FreeBSD.ORG         | TCP/IP since RFC 956
>>> > FreeBSD committer       | BSD since 4.3-tahoe
>>> > Never attribute to malice what can adequately be explained by
>>> incompetence.
>>>
>>>
>>
>