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

Re: HTTP 2.0 in the clear and over TLS

From: Peter Lepeska <bizzbyster@gmail.com>
Date: Mon, 29 Jul 2013 19:12:17 -0400
Message-ID: <CANmPAYEsngMs+x3WLrUm10YRCoi2vrnzKDDt_N+5V9fdcqk9YA@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: "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>
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:12:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC