tis 2006-09-19 klockan 10:02 -0700 skrev Mark Nottingham: > 1) Squid supports HTTP/1.0-style persistent connections; i.e., if it > gets a request with a Connection: keep-alive header in it, it will > reuse the connection. Yes. > However, if it receives a HTTP/1.1 request, it will fall back to one- > request-per-connection. Since pconns are the default in HTTP 1.1, why > not use them? Because we don't know the HTTP/1.1 client knows HTTP/1.0-style persistent connections. > 2) Squid still sends Proxy-Connection headers. As far as I can see, > they're not required by any modern implementations; everybody > understands Connection. Maybe it's time to stop generating them? You mean sending "Connection: keep-alive" instead of "Proxy-Connection: keep-alive"? It's a bit of a grey zone as neither is defined in any standard.. > 3) Squid can't persist client-side connections if it doesn't have a > Content-Length handy, so if the origin server doesn't provide one, > it'll close. However, responses cached by Squid -- by their very > nature -- have a C-L available to Squid, even if the origin server > doesn't send one. Since content generated by scripts often doesn't > have C-L set, but can sometimes be cacheable, it would be a nice > optimisation to synthesise the response body length if you don't have > a C-L on a cached response. Has anyone attempted this? It's possible (and not even difficult). Think we even did so at some point in time. I think the main reason why it isn't done is because of HTTP/1.0 signaling using "close" to mark the end of the object we are not really sure the object isn't truncated as most software errors and several network errors is signaled in the same manner.. Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
