Re: A proposal

The current spec already allows plain http2. What does your proposal
try to achieve? My impression was that you want to make it more
reliable on open web. But later you sounded like you want to make it
less reliable. (In no way I'm trying to question your intention; this
thing is too complicated and we are all lost in words)



On Sun, Nov 17, 2013 at 3:19 PM, James M Snell <jasnell@gmail.com> wrote:
> The proposal is to make it possible but with additional steps.  As opposed
> to the other proposal that says no plaintext http/2 at all.
>
> On Nov 17, 2013 1:17 PM, "Zhong Yu" <zhong.j.yu@gmail.com> wrote:
>>
>> 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:27:37 UTC