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