- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Tue, 03 Apr 2012 11:11:15 +1200
- To: <ietf-http-wg@w3.org>
On 03.04.2012 08:56, Adrien W. de Croy wrote: > ------ Original Message ------ > From: "Brian Pane" >>On Mon, Apr 2, 2012 at 8:16 AM, Poul-Henning Kamp wrote: >> >>> >>>In message >>> <CAAbTgTs55FmKP+HOKhNOz-q_SY1cBec7XLpxqruhFN-+TxtieA@mail.gmail.com> >>>, Brian Pane writes: >>> >>> >>>> >>>>In terms of performance, that's a step backwards from SPDY in two >>>> ways: >>>> >>>>- An additional round trip is needed to negotiate the use of >>>> HTTP/2.0. >>>> >>> >>> >>>You mean that it suffers from being interoperable with HTTP/1.1 ? >>> >> >> >>SPDY also is interoperable with HTTP/1.1 -- it can cleanly SSL-tunnel >>through intermediaries >> > for now. > >> -- without adding that extra round trip. >> Speaking for Squid we already decrypt CONNECT tunnels for content filtering and intercept TLS connections on arbitrary ports for same. AFAIK, Squid was one of the last proxy intermediaries to add this capability. I would not be overly surprised if installations with those features enabled were the 10-15% of failed/broken connections that were referred to earlier in reference to pipelined Upgrades, due to SPDY and WebSockets native support not being present in the middleware handlers yet. AYJ
Received on Monday, 2 April 2012 23:11:42 UTC