Re: [squid-users] Persistent Connections

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@yahoo-inc.com