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