Re: A proposal

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