Re: Squid-2.5 ICAP client

Hello Henrik,
Thanks for your interest/time in the icap related changes...It is also
good to know that my changes are not so out of the way..... Please find
my comments inline...

Henrik Nordstrom wrote:
>
> Ok. So if conn->me.sin_family is not set then the call came from
> icapReqModReadReply, and the conn and filedescriptor is that of the ICAP
> server and not the original client? Ugly but works I guess.
ya ....

>
> Need to look into how this affects handling of persistent and/or
> pipelined client connections. There was some subtle bugs in 2.5.STABLE1
> in this area (and there quite likely is more), and clientReadRequest is
> a bit sensitive to this type of changes. How/when/why Squid schedules
> reading of the next request on a persistent client connection is not
> entirely obvious in the current design of clientReadRequest, and with
> your magic connections in the mix it becomes even less obvious..

My changes get included only if enable-icap is true... else HS_FEAT_ICAP
is not defined. I am not sure howmany developers are running squid with
icap on though.

>
> Am I correct in assuming that icapReqModReadReply decomposes the faked
> conn structure on return from clientReadRequest and then initiates
> continued processing of the ICAP modified request as if it was the
> original request? Checking.. yes, seems to be the case.
>
> The pieces is starting to fall into place now on how you have hooked
> ICAP request modifications into Squid. Thanks for your help in
> explaining this. More questions will probably follow later.
>
> Hmm.. immediately there is one additional question on clientReadRequest
> when called from icapReqModReadReply. How does it handle the case where
> the full request could not be read immediately? To me it looks like the
> connection gets stuck in such case with clientReadRequest installed as a
> read handler for the ICAP connection, but nobody taking care of kicking
> the requests going again..

I am not sure I understand your question fully.. please explain... If
you mean "continue after being defered", then the fact that
commSetDefer() is not used on icap_fd before calling clientReadRequest
from icapReqModReadReply unlike a similar call from httpAccept()
probably does the trick.

thanks and regards
Geetha
Received on Fri Mar 28 2003 - 05:06:53 MST