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

Re: Ascii-based SPDY "compression" idea

From: Tim Bray <tbray@textuality.com>
Date: Sun, 1 Apr 2012 11:17:36 -0700
Message-ID: <CAHBU6ityu-2rOeXD_wcNGBObzS0AFT6jYyX_Tpna28iJ2Rq3xw@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: ietf-http-wg@w3.org
This works IF all the requests get sent to the same web server.  This
is quite possibly not true in particular with GET requests to a large
web-facing property with a sharded cache.  At a deeper level, it
requires more server state, which can be quite expensive in some

But still, quite a clever idea.


On Sun, Apr 1, 2012 at 9:50 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:
> >From the SPDY whitepaper, the primary performance benefit of header
> compression is in the upload direction. The benefit can be as much as a 1
> second impact for slow DSL (375 Kbps) links based on these tests. This is
> primarily due to long repeating strings in URLs, User Agents, and Cookies.
> Ideally we could find a way to reduce the bytes associated with these
> headers without obscuring them.
> 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.
> This allows us to consider other "compression" schemes for SPDY that will
> maintain transparency on the wire, or at least make it easier for tools to
> be built to interpret the headers. For instance, in a given TCP connection /
> SPDY session, HTTP headers in GETs and responses can be dropped if they have
> the same value as previous. If different from previous, only differences can
> be sent. This would immediately drop User Agent headers from all but the
> first GET. Additionally requests would contain only cookies whose values are
> changing, similar to the way that Set-Cookie works in HTTP responses today.
> Even URLs could use relative paths from the previous object.
> This would provide some of the benefit of header compression without any of
> the opaqueness downside.
> Peter
> On Sun, Apr 1, 2012 at 12:39 AM, Willy Tarreau <w@1wt.eu> wrote:
>> On Fri, Mar 30, 2012 at 03:22:12PM +0200, Mike Belshe wrote:
>> > What is "transparency on the wire"?  You mean an ascii protocol that you
>> > can read?  I don't think this is a very interesting goal, as most people
>> > don't look at the wire.
>> I agree with you here Mike, despite being used to look at network captures
>> all the day and testing proxies with "printf|netcat" at both ends. But we
>> must admit that if developers need tools, they will develop their tools.
>> Having an HTTP option for netcat would work well, or even having an
>> 1.1-to-2.0
>> and 2.0-to-1.1 message converter on stdin/stdout would do the trick. So I
>> prefer to lose the ability to easily debug and have something efficient
>> than
>> the opposite. And it costs me a lot to say this :-)
>> Willy
Received on Sunday, 1 April 2012 18:18:05 UTC

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