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
On Friday, March 22, 2024 at 11:02:51 PM EDT, Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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>
>
>
> Sharing the problematic ICAP response (header) in a raw packet capture
> format (to preserve important details) may also be very useful.
>
>
> HTH,
>
> Alex.
>
>
> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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>
>
>
> Sharing the problematic ICAP response (header) in a raw packet capture
> format (to preserve important details) may also be very useful.
>
>
> HTH,
>
> Alex.
>
>
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
