Re: A proposal

It intentionally pushes people towards https in the default most common
cases while making it still possible to do plaintext...
On Nov 17, 2013 1:27 PM, "Zhong Yu" <zhong.j.yu@gmail.com> wrote:

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