Re: [squid-users] GET/PUT Question - AGAIN

Hello,

> The places in Squid generating HTTP replies (which is somewhat different
> from relaying an upstream reply) are:
>
> ftp.c
> gopher.c
> errorpage.c
> cachemgr.c
> internal.c
>
> All uses httpReplySetHeaders() to initiate the HTTP reply headers, and
> then adds/deletes what is required from there..

Okay!

The PushCache patched version never calls httpReplySetHeaders().

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?

The PushCache version does call clientProcessRequest() (client_side.c),
but it gets caught by:

<snip>
} else if (r->method == METHOD_PUT) {
<snip>

that must not have the logic to tell squid to keep the connection
alive. If I knew how squid actually keeps the connection alive, then I
could include it here.

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? I do call clientReadRequest() on FD 12, but then
I call comm_add_close_handler() on FD 12 without calling
httpReadReply().

When I am doing GETs, both clientReadRequest() and httpReadReply() get
called on different FDs.

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:

"no data to process ((11) Resource temporarily unavailable)"

I never get this with the pushes!

Thanks,
Murrah Boswell
Received on Fri Oct 08 2004 - 15:11:45 MDT