After some reflection (and coffee!), I'm not sure I understand your
point. If the proxy synthesises the Content-Length from the stored
response, it can definitively count the bytes it's to send and always
delimit the response correctly. While it's true that the response may
be incomplete from the server's point of view, this is an entirely
separate issue -- one that Squid already has today.
Cheers,
On 2006/09/19, at 2:45 PM, Mark Nottingham wrote:
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...
--
Mark Nottingham
mnot@xxxxxxxxxxxxx