Re: Ascii-based SPDY "compression" idea

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.

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

Received on Monday, 2 April 2012 13:36:47 UTC