[squid-users] Error during ICAP RESPMOD

[Arun Kumar]

 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
https://drive.google.com/file/d/19yirXfxKli7NXon4ewiy-v3GpLvECT1i/view?usp=sharing

    On Wednesday, April 24, 2024 at 09:16:23 PM EDT, Arun Kumar <s_p_arun at yahoo.com> 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
cache.zip


|  | 
cache.zip
 |



| 
| 
|  | 
cache.zip


 |

 |

 |






    On Friday, March 22, 2024 at 11:02:51 PM EDT, Alex Rousskov <rousskov at measurement-factory.com> 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> 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.
> 
> 

    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20240425/dce138fc/attachment-0001.htm>