Re: A proposal

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