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

Re: New Version Notification for draft-nottingham-http2-encryption-02.txt

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Wed, 18 Dec 2013 19:30:05 +1000
Message-ID: <CACweHNB7C3rSODPBc9sAHWcBoX=0HQ6gHp69sk2r9Tn2nWACBg@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 18 December 2013 18:00, Eliot Lear <lear@cisco.com> wrote:

> > Again, no one has proposed that the HTTP/2 spec say that it only works
> across TLS.
> And now let us add up the previous email with my statement above.  A
> lack of interest from non-browsers and a statement from most browser
> people that they aren't going to implement HTTP/2 upgrade means that it
> will only work over TLS.

"We are one browser vendor who is in support of HTTP 2.0 for HTTP:// URIs.
 The same is true for our web server."  --Rob Trace from Microsoft.

They might be market losing share, but I think IE still counts.  I have
trouble reconciling the above statement with your assertion that browsers
won't implement upgrade, since I don't know how else IE could support
HTTP/2 for http:// URIs, unless some other magic pre-negotiation mechanism
is invented (or possibly a best-effort fallback behaviour: try /2 first, if
it fails try /1; but I digress).  As noble or whatever as the effort to
promote TLS-everywhere may be, I've seen enough points raised in this
discussion to argue the case against fully encrypted connections in some
contexts, and a case *for* HTTP2 (and its improvements) on connections in
an intersecting set of contexts.  Some of those even included browser-based
access (so I believe IE is doing the Right Thing™).

The condition "that HTTP2 will only be implemented by browsers via TLS" is
flawed, and therefore your first list (1-2) is moot.  Point (1) is already
off the table (or on the table, depending on your preferred idiomatic
phrase for "not up for discussion"), and point (2) is only true if you
change it to "... hence encrypted-only HTTP2 is not a replacement...",
which is a tautology.  The charter as it stands, designing a full
replacement for the HTTP/1 spec, is, I believe, correct.  Implementations
are free to cherry-pick the bits they support, as long as their failure
modes for all the other bits fit the spec.  WRT browsers, if they never
make a connection that *isn't* over TLS, then that's completely up to them.

This doesn't in any way diminish your further list (A-D) for options if and
when encryption/security is used, but it makes it less of (or completely
not) a priority for this WG; instead it's on whoever decides not to
implement unencrypted HTTP/2.

  Matthew Kerwin
Received on Wednesday, 18 December 2013 09:30:35 UTC

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