Re: Ascii-based SPDY "compression" idea

On Mon, Apr 2, 2012 at 3:36 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> On 3/04/2012 12:10 a.m., William Chan (陈智昌) wrote:
>
>> It's unclear to me the point that you're making. Above, Peter said "Since
>> a SPDY session is associated with a single TCP connection, we can assume
>> all GETs on that connection are being routed to the same web server." to
>> which you said "I think that is an unwarranted assumption."
>>
>> So, just to clarify, we're on agreement that all GETs are being routed to
>> the same HTTP router, right? I understand that intermediary authors have
>> concerns about the use of compression at all and also about the type of
>> compression, but I think that's orthogonal to Peter's above point.
>>
>
> The assumption that its a web server which is receiving the requests is
> not a valid one. Transparent multiplex/aggregation/load balancer proxy is
> just three types of intermediary which violate that assumption, and we have
> not got anywhere near the more complex things like TCP splitters. SPDY
> using TLS avoided many of them so far, whatever gets approved they will
> likely all be updated to hook into the HTTP/2 protocol like they do HTTP/1.


Yes yes, totally agreed here. It clearly could be an intermediary.


> Assuming that the host can be bound to the TCP layer details prohibits all
> types of multiplexing, virtual hosting and intermediary pipelining from
> being done in the middle. The net result of that is to cap ISP at around
> concurrent 64K pipelines per box, with each restricted to only one origin
> servers traffic. That is an unreasonably low limit.
> Unless the middleware add layering hacks to transit the details over
> multiplexed connections. Which can only lead to interoperability pain.


> AYJ
>
>
>