- From: Fred Akalin <akalin@google.com>
- Date: Tue, 30 Jul 2013 01:38:16 +0200
- To: Peter Lepeska <bizzbyster@gmail.com>
- Cc: William Chan (陈智昌) <willchan@chromium.org>, "emile.stephan@orange.com" <emile.stephan@orange.com>, Michael Sweet <msweet@apple.com>, Eliot Lear <lear@cisco.com>, Zhong Yu <zhong.j.yu@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CANUYc_R2omr7JC5G5oLcvX-sdp7bSpW4b=cg=vDAqHAmQo9q8Q@mail.gmail.com>
Why would HTTP 2.0 be faster in the clear than over TLS? On Tue, Jul 30, 2013 at 1:12 AM, Peter Lepeska <bizzbyster@gmail.com> wrote: > HTTP 2.0 in the clear will be faster than over TLS. It will be interesting > to see if Google will continue to trade speed for privacy when the standard > supports a faster option. > > Peter > > > On Mon, Jul 29, 2013 at 5:01 PM, William Chan (陈智昌) <willchan@chromium.org > > wrote: > >> Sorry, I am inexact. Some people may have previously said otherwise, but >> currently to my knowledge no one is vocally opposing including a HTTP/2.0 >> in the clear mechanism in the spec, and the current draft spec does provide >> such a mechanism. >> >> >> On Mon, Jul 29, 2013 at 2:00 PM, William Chan (陈智昌) < >> willchan@chromium.org> wrote: >> >>> No one has said otherwise. Please see the section in the spec where we >>> provide a way to negotiate HTTP/2.0 in the clear via HTTP Upgrade: >>> http://http2.github.io/http2-spec/#discover-http. >>> >>> >>> On Mon, Jul 29, 2013 at 9:37 AM, <emile.stephan@orange.com> wrote: >>> >>>> Hi,**** >>>> >>>> ** ** >>>> >>>> HTTP2 must work in the clear and over TLS. This is required because >>>> HTTP1.1 and HTTP2 must coexist to ease the migration to HTTP2, and to >>>> accelerate HTTP2 deployments. **** >>>> >>>> ** ** >>>> >>>> Regards**** >>>> >>>> Emile**** >>>> >>>> ** ** >>>> >>>> *De :* Michael Sweet [mailto:msweet@apple.com <msweet@apple.com>] >>>> *Envoyé :* dimanche 28 juillet 2013 14:12 >>>> *À :* Eliot Lear >>>> *Cc :* William Chan (陈智昌) ; Zhong Yu; HTTP Working Group >>>> *Objet :* Re: HTTPS 2.0 without TLS extension?**** >>>> >>>> ** ** >>>> >>>> ... and don't forgot some of the more obscure usage of HTTP, such as >>>> HTTP over USB in the USB-IF's IPP USB Specification:**** >>>> >>>> ** ** >>>> >>>> http://www.usb.org/developers/devclass_docs**** >>>> >>>> >>>> >>>> **** >>>> >>>> There isn't much point in using TLS over USB (and a lot of cost issues >>>> for that class of printer against it), and we need to continue to use the >>>> same USB end points/interfaces, so upgrade remains an important feature of >>>> HTTP/2.0 for me/Apple...**** >>>> >>>> >>>> >>>> **** >>>> >>>> >>>> Sent from my iPad**** >>>> >>>> >>>> On 2013-07-28, at 12:46 AM, Eliot Lear <lear@cisco.com> wrote:**** >>>> >>>> ** ** >>>> >>>> On 7/23/13 7:34 PM, William Chan (陈智昌) 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.**** >>>> >>>> >>>> Not only that, I don't think we can reasonably call this HTTP 2.0 if we >>>> have no path to do it in the clear.**** >>>> >>>> _________________________________________________________________________________________________________________________ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>>> they should not be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>>> Thank you. >>>> >>>> >>> >> >
Received on Monday, 29 July 2013 23:38:43 UTC