Re: Squid-2.5 ICAP client

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.

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..

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..

Regards
Henrik

ons 2003-03-26 klockan 13.27 skrev Geetha Manjunath:
> Hello Henrik,
>
> This piece of code is related to the call to clientReadRequest from the
> function icapReqModReadReply in icap.c . The function
> icapReqModReadReply reads the modified http request from the icap server
> - which is in reply to a reqmod request - and processes this new
> request. You will notice that I am creating a conn structure there to
> simulate a client connection.
>
> Though it is a bit of a hack, I saw that a lot of existing squid code
> could be easily resused by doing this and also I thought this was a nice
> way of coming into the main stream of request processing. I just had to
> short circuit the access check since it was already done on the orig
> request - and conn->me.sin_family acts as a flag there to do that.
>
> Please let me know if this breaks some things elsewhere - I did not come
> across any such situation in my testing though. Also, if I can acheive
> the same thru some other means, please let me know..
>
> But this works ;-)
>
> regards
> Geetha

-- 
Henrik Nordstrom <hno@squid-cache.org>
MARA Systems AB, Sweden