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

Re: Proposal: Explicit HTTP2S proxy with any node refusal

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 27 Nov 2013 20:58:54 +0000
To: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
Cc: "Peter Lepeska" <bizzbyster@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <emb74d3d20-bf6e-4184-a925-9d567573c187@bodybag>
my main issue wasn't so much the client to proxy TLS 3 way, but the 
proxy to server

TCP 3 way handshake
TLS 3 way handshake
another TLS 3 way handshake.

That's a lot of RTs.  Sprinkly 300ms latency on each RT and you have a 


------ Original Message ------
From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Peter Lepeska" <bizzbyster@gmail.com>; "ietf-http-wg@w3.org" 
Sent: 28/11/2013 9:53:08 a.m.
Subject: Re: Proposal: Explicit HTTP2S proxy with any node refusal
>Le Mer 27 novembre 2013 00:40, Adrien de Croy a écrit :
>>  fundamentally this proposes a compromise between level of trust of 
>>  proxy vs performance.
>>  Since we don't trust the proxy not to alter content, we have to 
>>  extra round trips to set up the second layer of TLS
>Consider that a browser is likely to establish a tls channel to the
>proxies active on his network as soon as the user starts browsing, so 
>there will be a penalty for the first objects but the next ones won't 
>the difference (and properly designed web sites will benefit from the
>caching at the proxy layer.
>I said proxies because we, for example, run a high-availability setup 
>each browser gets two proxies on two different physical sites at 
>(much more reliable to have browsers failover or load-balance as they 
>depending on network conditions)
>Nicolas Mailhot
Received on Wednesday, 27 November 2013 20:59:28 UTC

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