- From: Zhong Yu <zhong.j.yu@gmail.com>
- Date: Tue, 23 Jul 2013 13:46:44 -0500
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I agree TLS-ALPN is much better than TLS-Upgrade, but it'll take the rest of the world some time to get there. Allowing TLS-Upgrade meanwhile probably will not lessen the motivation to deploy ALPN, since it's in the best interest of all clients and servers to reduce a round trip. *If* the spec allows TLS-Upgrade, some servers will use it before they can do ALPN, and some clients will support it. Chrome will face the heat - a competitor browser can talk to a server in HTTPS/2.0 with Upgrade, yet Chrome can only talk to it in HTTPS/1.1. Will Chrome stick to its principle and refuse to speak with the vulgar Upgrade? I bet a lunch that it will budge. Therefore if the spec allows TLS-Upgrade, it might as well mandate it. The other option is to absolutely forbid TLS-Upgrade and disown any implementation that does it, deliberately or accidentally (the latter being more likely). Zhong Yu On Tue, Jul 23, 2013 at 12:34 PM, William Chan (陈智昌) <willchan@chromium.org> wrote: > FWIW, it seems reasonable to me to have the spec allow HTTPS 2.0 without TLS > extension. If you want to Upgrade, be my guest. I have no plans for my > browser to support that, and I don't think Google servers will support it > either, because we care strongly about the advantages of TLS-ALPN vs > Upgrade. > > IIRC, Twitter doesn't use NPN for the same reasons (lack of TLS extension > support on certain mobile clients). I believe they don't care about public > interop though, they just use dedicated VIPs with clients they control. > > > On Mon, Jul 22, 2013 at 5:06 AM, Zhong Yu <zhong.j.yu@gmail.com> wrote: >> >> The draft mandates TLS extension ALPN for any https 2.0 connections, >> but why is that necessary? Why can't we also establish an https 2.0 >> connection through the Upgrade mechanism, without ALPN? TLS extension >> may not be available/convenient on some platforms for some time; >> requiring it may discourage some potential implementers. >> >> Zhong Yu >> >
Received on Tuesday, 23 July 2013 18:47:13 UTC