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
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
