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}^MparseHeaders:
parse ICAP headersparsePart: have 144 head bytes to parse; state: 0
parsePart: head parsing result: 0 detail: 600
On Monday, March 18, 2024 at 11:21:02 PM EDT, Alex Rousskov
<rouss...@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
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@lists.squid-cache.org
https://lists.squid-cache.org/listinfo/squid-users
