Re: A proposal

On Sun, Nov 17, 2013 at 2:57 PM, James M Snell <jasnell@gmail.com> wrote:
> 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.

I'm confused - is it your objective to make plain http2 more
undependable on the broader web? Since your wording sounds like that.

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

Received on Sunday, 17 November 2013 21:18:13 UTC