[squid-users] Identifying the source of Invalid-request (squid 3) -> error:transaction-end-before-headers (Squid 4)

[Jester Purtteman]

Hello Alex et al.

So, life got on top of me instead, and I haven't had time to do much testing.... Well, not totally true, did some testing but haven't discovered anything useful.  But, from the "new and interesting" department, I updated 3.5 build r14102, and I am not seeing any of the 'invalid-request' lines anymore.  Don't know what to make of that, but could be, problem solved.  

Jester Purtteman, P.E.
OptimERA Inc

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov at measurement-factory.com]
> Sent: Saturday, October 15, 2016 5:27 PM
> To: squid-users at lists.squid-cache.org
> Cc: Jester Purtteman <jester at optimera.us>
> Subject: Re: [squid-users] Identifying the source of Invalid-request (squid 3) -
> > error:transaction-end-before-headers (Squid 4)
> 
> On 10/15/2016 05:16 PM, Jester Purtteman wrote:
> > The packet capture idea is a good one too, I'll do that as well.
> > Similar issue (sifting a small amount of info out of an ocean of data)
> > but I think valuable.
> 
> With a packet capture and a matching access.log, it is easy to find the
> offending connections without Squid-specific knowledge because you can
> ask Wireshark or a similar tool to locate the packets that match the logged IPs
> and ports (the ones on the error:... lines in access.log).
> After that, you just follow the TCP stream you found and look at its packet
> payload to identify the protocol/intent...
> 
> With cache.log, the procedure is similar but there is no nice interface to
> "follow the identified transaction". There are some very useful scripts that
> can follow descriptors and internal Squid "jobs", but they do require some
> low-level Squid-specific knowledge and experience to operate correctly
> (unfortunately). Besides, you may not see the payload, especially if Squid
> does not try to parse it.
> 
> Alex.