W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: A proposal

From: Zhong Yu <zhong.j.yu@gmail.com>
Date: Sun, 17 Nov 2013 15:51:12 -0600
Message-ID: <CACuKZqHSJ01arPEhv38Pv6Kzmz-O7=gztytvSBT_DUxOdT2YGw@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Tim Bray <tbray@textuality.com>, HTTP Working Group <ietf-http-wg@w3.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Mike Belshe <mike@belshe.com>
So it's a sin tax:) There are two problems:
1. people who want plaintext http2 do not think it is a sin.
2. the tax is too high which practically outlaws plaintext http2.

On Sun, Nov 17, 2013 at 3:44 PM, James M Snell <jasnell@gmail.com> wrote:
> 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.
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
Received on Sunday, 17 November 2013 21:51:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC