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

Re: Ascii-based SPDY "compression" idea

From: Willy Tarreau <w@1wt.eu>
Date: Sun, 1 Apr 2012 20:14:35 +0200
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20120401181435.GA30668@1wt.eu>
Hi Peter,

On Sun, Apr 01, 2012 at 12:50:20PM -0400, Peter Lepeska wrote:
> From the SPDY whitepaper <http://dev.chromium.org/spdy/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.

The goal is now to optimize every agent in the chain, not to make it easy
to read them from a human eye. Something like 1 requests over 1 billion is
read by a human, yet networks are full of them and parsers have a lot of
difficulties trying to get them right because they're made for humans.
Don't get me wrong, I *love* to read captures and to quickly spot what's
right or wrong, but people who do this like me are also able to develop
some additional tools to continue doing this.

> 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.

You should then take a look at what is proposed in our draft here, as it's more
or less what you're describing, with binary-encoded header field names in order
to save more space (stop sending "if-modified-since" for instance) :


Best regards,
Received on Sunday, 1 April 2012 18:15:03 UTC

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