Re: A proposal

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