On Sun, 25 Apr 2004, osuser os wrote:
> Hi,
> Thanks for the reply.
> When I set the quick_abort_min directive to be a large number such as 1000
> KB, then I see that the files are getting cached as expected. Hence it seems
> that quick abort is indeed the problem.
>
> Can you give more details about how Squid determines that the client has
> aborted.
Squid does not actually care why the client disconnected from the request
in the quick_abort_* directives. These directives apply on what Squid
should do on a request where there no longer is any clients waiting for
data. A client who has already received all it wants from a Range request
logically disconnects from the forwarded request.
It is very hard to find a accurate balance when allowing Squid to fetch
content not explicitly asked for by any client. In whatever combination
you can easily end up wasting a lot of bandwidth.
Range requests: Client only requests a small part of the file then
decides the rest is not wanted. Or if range_offset_limit is large times
out while waiting for the reply.
Aborted requests: More or less the same. Client or another client may or
may not attempt to finish the retreival later.
range_offset_limit was designed for handling the case where the client
starts by downloading the end of the object, then the rest of the object.
This is seen for example when using the Acrobat Reader plugin which
fetches the table of contents at the end of PDF files first.
> Even though the socket connection is alive, I see that Squid
> determines that the connection is aborted.
Squid works with HTTP messages, not neccesarily sockets..
> What can client do (any specific header for example) to prevent squid from
> thinking that the client is aborting?
In this specific case, not use a Range header..
Suggestions on how you think Squid should handle these cases better is
welcome. Patches even more so.
Regards
Henrik
Received on Sun Apr 25 2004 - 23:20:12 MDT
This archive was generated by hypermail pre-2.1.9 : Fri Apr 30 2004 - 12:00:02 MDT