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

Re: Ascii-based SPDY "compression" idea

From: 陈智昌 <willchan@chromium.org>
Date: Mon, 2 Apr 2012 16:18:43 +0200
Message-ID: <CAA4WUYgShzXePuqx+cVJ0NdUSyt4E2__FhuVZEQQy3FZ3z_zpg@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org
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.

Received on Monday, 2 April 2012 14:19:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:59 UTC