[squid-users] Error during ICAP RESPMOD

[Alex Rousskov]

On 2024-04-24 21:23, Arun Kumar wrote:
> I managed to reproduce the problem in my personal setup. Please find the 
> cache logs when the problem is reproduced. Squid version is 5.8

Just to close this old thread: My response[1] on a newer thread 
(analyzing the same log file you shared on this thread) supports and 
details the "HTTP body instead of an ICAP response header" theory I 
suggested further below (before you shared that log file).

[1]:
https://lists.squid-cache.org/pipermail/squid-users/2024-May/026634.html

Alex.


> On Friday, March 22, 2024 at 11:02:51 PM EDT, Alex Rousskov wrote:
> 
> 
> On 2024-03-22 13:11, Arun Kumar wrote:
>  > The lines above are. The content-length is 138 (8a in hex), but the
>  > bytes are 144. Could this be the reason?
>  >
>  > parseMore: have 144 bytes to parse [FD 14;RBG/Comm(14)wr job24]
>  > parseMore:
>  > 8a^M
>  > {"activity":"Make a simple musical
>  > 
> instrument","type":"music","participants":1,"price:0.4,"link":"","key":"7091374","accessibility":0.25}^M
>  > parseHeaders: parse ICAP headers
>  > parsePart: have 144 head bytes to parse; state: 0
>  > parsePart: head parsing result: 0 detail: 600
> 
> 
> I cannot be sure based on the tiny snippets shared so far, but it
> _looks_ like Squid expected an ICAP response header and got an ICAP
> response body chunk instead. It is also possible that we are looking at
> log lines from two unrelated ICAP transactions, or I am simply
> misinterpreting the snippets.
> 
> If you want a more reliable diagnosis, then my earlier recommendation
> regarding sharing (privately if needed) the following information still
> stands:
> 
> * compressed ALL,9 cache.log and
> * the problematic ICAP response in a raw packet capture format.
> 
> 
> HTH,
> 
> Alex.
> 
> 
> 
>  > On Monday, March 18, 2024 at 11:21:02 PM EDT, Alex Rousskov
>  > <rousskov at measurement-factory.com 
> <mailto:rousskov at measurement-factory.com>> wrote:
>  >
>  >
>  > On 2024-03-18 18:46, Arun Kumar wrote:
>  >
>  >  > Any idea, the reason for error in ModXact.cc parsePart fuction.
>  >  > Happening during parsing the response from ICAP
>  >  >
>  >  >
>  >  > parsePart: have 144 head bytes to parse; state: 0
>  >  > parsePart: head parsing result: 0 detail: 600
>  >
>  >
>  > AFAICT, Squid considers received ICAP response header malformed. More
>  > than five possible problems/cases may match the above lines. The answer
>  > to your question (or an additional clue!) is in different debugging
>  > output, possibly logged somewhere between the two lines quoted above.
>  > The right debugging lines may be visible in "debug_options ALL,2 58,5,
>  > 93,5" output, but it is usually best to share compressed ALL,9 logs
>  > (privately if needed).
>  >
>  > 
> https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction> <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction <https://wiki.squid-cache.org/SquidFaq/BugReporting#debugging-a-single-transaction>>
>  >
>  >
>  > Sharing the problematic ICAP response (header) in a raw packet capture
>  > format (to preserve important details) may also be very useful.
>  >
>  >
>  > HTH,
>  >
>  > Alex.
>  >
>  >
>