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
