Re: Ascii-based SPDY "compression" idea

"it requires more server state, which can be quite expensive in some cases."

Right, it trades off byte savings and the need to deal with more per
connection state on the server -- just like SPDY's compression.

About sending to the same server, I agree this could only be applied to
data across persistent HTTP connections or SPDY connections, both of
which will be terminated and parsed by a single server.

Peter

On Sun, Apr 1, 2012 at 2:17 PM, Tim Bray <tbray@textuality.com> wrote:

> 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
> cases.
>
> But still, quite a clever idea.
>
>  -T
>
> 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
> >>
>