Re: [squid-users] Persistent Connections

ons 2006-09-20 klockan 14:27 -0700 skrev Mark Nottingham:

> > Clients and servers SHOULD NOT assume that a persistent
> > connection is
> > maintained for HTTP versions less than 1.1 unless it is explicitly
> > signaled. See section 19.6.2 for more information on backward
> > compatibility with HTTP/1.0 clients.
>
> ... and one could argue that it's explicitly signalled by the Content-
> Length header in the response.

Not quite.. Content-Length is a HTTP/1.0 header with very well defined
semantics. It doesn't imply that the connection is persistent. The
exception being that no content-length and no chunked transfer encoding
automatically implies that the connection is certainly not persistent as
that's the only message delimiting method available then..

> Just thinking aloud -- the obvious solution to this is to make Squid
> HTTP/1.1.

Yes.

> Of course, that's a lot of work, but I wonder if it would
> be more manageable by going 1.1 on just the client side at first,

It's not really that much work to get Squid up to the level that
HTTP/1.1 message signaling works. Just needs chunked transfer encoding
on both sides.. Getting it up to the level that trailers also works
requires a bit more work, but shouldn't be that tricky in Squid-3 I
think..

The really big part is to assure HTTP/1.1 compliance, but it can be
debated how important that really is.. But as the two goes a little hand
in hand HTTP/1.1 for Squid never seems to get anywhere...

There was a transfer-encoding project for Squid some years ago, but it
died a slow death from being a bit too ambitious and handle all forms of
transfer encoding efficiently (not only chunked but also gzip &
deflate), and then getting wound up in design considerations if the
gzip/deflate should be cached or not..

Regards
Henrik