Re: A proposal

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.

Received on Sunday, 17 November 2013 20:16:14 UTC