W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Ascii-based SPDY "compression" idea

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Tue, 03 Apr 2012 11:11:15 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <205b1e9ea7a6882eebf855312e252a23@treenet.co.nz>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:59 GMT