On 2006/09/19, at 1:54 PM, Henrik Nordstrom wrote:
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.
A HTTP/1.0-style persistent connection is a form of a HTTP/1.1
persistent connection. I.e., sending this response
--->8---
HTTP/1.0 200 OK
Content-Length: nnn
Connection: keep-alive
[content]
---8<---
looks just like a HTTP/1.1 length-delimited response to a 1.1 client,
with two exceptions:
* An extra Connection token which it (possibly) doesn't know
anything about, and therefore can safely ignore
* The response is HTTP/1.0 instead of HTTP/1.1.
I think it's reasonable to expect a HTTP/1.1 client to be able to use
Content-Length to delimit the response; RFC2145 makes it clear that
the HTTP version isn't a contract about what mechanisms will be used
in the exchange, but an indication of the capabilities of the
implementations. A client that says it's HTTP/1.1 can use Content-
Length to enable persistent connections.
E.g., curl and Apple's Safari browser are HTTP/1.1 clients and they
don't send Connection: keep-alive, but they'll happily use persistent
connections with HTTP/1.0 servers.
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..
Yes. I'm just wondering why it's necessary to promote *two* non-
standard mechanisms...
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..
You mean from the origin server? Good point. Maybe if it were
configurable; this is most useful in an accelerator situation, where
the origin and the cache are more likely to have good connectivity...
Cheers,
--
Mark Nottingham
mnot@xxxxxxxxxxxxx
