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@xxxxxxxxxxxxxxxxxxxxxxx] > Sent: Saturday, October 15, 2016 5:27 PM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Cc: Jester Purtteman <jester@xxxxxxxxxxx> > Subject: Re: 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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
