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
[EMAIL PROTECTED]



Reply via email to