Re: Fwd: Squid ICAP client problems

Thanks for forwarding this, Henrik.

Hello Larry,

Sorry for this delayed reply..
> -----Original Message-----
> From: Rosenbaum, Larry M.
....
.........
>
> 1) (icap.c) There is a problem with the way icapRespModReadReply()
> tries to read the ICAP header without reading past the header. The
> current code does a recv() with the MSG_PEEK flag and a read_sz of
> 256 bytes, and if the buffer doesn't contain a double CRLF it
> doubles the read_sz and tries again. The problem with this approach
> is that it takes time for the socket to receive more bytes, and
> there is nothing in the loop to ensure that more bytes are read.
> For example,
>
> try #1 read_sz = 256, len = 38
> try #2 read_sz = 512, len = 38 (i.e. it reads the same 38 bytes
> again) try #3 read_sz = 1024, len = 38
> ...
> try #n read_sz = max, len = 38
>
> so it is possible to exit the loop after many iterations without
> reading any more bytes than you got on the first try. One possible
> fix would be to turn off MSG_PEEK and read repeatedly until you get
> to the end of the headers, and then pass the extra bytes to the
> function that parses the rest of the message, but I don't know if
> the code structure permits this.
>
> The same issue probably applies to icapReqModReadReply().
>

Yes, you are right here - but this case would probably show up only with
buggy ICAP servers that do not end ICAP headers with \r\n\r\n . The rest
of code catches this error. Actually it signals an HTTP internal error
rather than the suggested "did not find a proper ICAP response". We
probably should add a separate error code for this.

Also, clientReadRequest cannot handle the partial header and so on - to
remove MSG_PEEK.

Out of curiosity, did you encounter this problem during any test with
squid client or thru' a code review?

Thanks for analysing.

regards
Geetha
Received on Mon Jun 23 2003 - 06:14:50 MDT