Re: HTTP 2.0 in the clear and over TLS

[Peter Lepeska <[e-mail]>]

No need to speculate about Google but in general content owners will have a
tough decision IMHO because TLS costs 1 additional round trip per domain at
minimum (and the number of domains per web site is increasing --
http://httparchive.org/trends.php#numDomains&maxDomainReqs). This gets to
be significant, especially if you are audacious about performance goals --
http://www.strangeloopnetworks.com/blog/are-your-performance-goals-audacious-enough/
.

Peter


On Mon, Jul 29, 2013 at 7:58 PM, William Chan (陈智昌)
<[e-mail]>wrote:

> I'm not really interested in discussing speculations about what we
> (Google) will do in the future. I think we've already made our stance
> relatively clear.
>
>
> On Mon, Jul 29, 2013 at 4:12 PM, Peter Lepeska <[e-mail]>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 (陈智昌) <
>> [e-mail]> 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 (陈智昌) <
>>> [e-mail]> 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, <[e-mail]> 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:[e-mail] <[e-mail]>]
>>>>> *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 <[e-mail]> 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.
>>>>>
>>>>>
>>>>
>>>
>>
>