On Fri, 8 Oct 2004, OTR Comm wrote:
I don't understand something (lots actually). What is the actual switch that tells squid to keep the connection alive? That is, how does sending a reply header trigger this keep alive state?
It depends, but for the connection to be able to be kept persistent in HTTP/1.0 the following criterias need to be fulfilled:
a) The reply-body must have a known length, as indicated by the Content-length header.
b) The client must have requested a persistent connection via the (Proxy-)Connection: keep-alive header.
c) The server must acknowledge the request to keep the connection persistent by answering with a (Proxy-)Connection: keep-alive header.
One thing I just noticed in the PushCache patch is that I call comm_add_close_handler(), but I don't call httpReadReply() when I am pushing files. Does httpReadReply() have something to do with keeping the connection alive?
No. httpReadReply is about reading HTTP replies from HTTP servers.
When I am doing GETs, both clientReadRequest() and httpReadReply() get called on different FDs.
What you need to worry about is what happens with the client fd only, not any server filedescriptors to web servers..
BTW, the first and last FD always seems to be FD 12. This is true with GETS and pushes (i.e., PUTs). Also, the last thing a GET session does is clientReadRequest() on FD 12, and always comes back with:
The fd number is irrelevant, it is just the first free fd at the time.
Regards Henrik
