Amos, tell me what more you need to analyze the incident. Every time that I access to this http://www.rionegro.gov.ar <http://www.rionegro.gov.ar/download/images/00033494.jpg> I have the error TCP_MISS_ABORTED/000, but also if access to ssl version https://www.rionegro.gov.ar the error NOT occur. <http://www.rionegro.gov.ar/download/images/00033494.jpg>
regards. <http://www.rionegro.gov.ar/download/images/00033494.jpg> 2018-02-28 1:00 GMT-03:00 Amos Jeffries <squ...@treenet.co.nz>: > On 28/02/18 15:12, L A Walsh wrote: > > Juan Manuel P wrote: > >> I am using Squid Cache: Version 3.5.12, but some pages give me the > >> next error: > >> > >> 1/Feb/2018:18:14:40 -0300 || - || 10.12.43.20 || > >> TCP_MISS_ABORTED/000|| GET || > >> http://www.rionegro.gov.ar/download/images/00033494.jpg > >> <http://www.rionegro.gov.ar/download/images/00033494.jpg> || - > > ---- > > I don't know what causes it, but I see it frequently and have for a > few > > years. Currently am running 3.15.3. Was told it might be due to some > > Er, which version exactly? > > > cache corruption -- but having removed it several times over the past > > few years, I sorta doubt that. Also, I'm attempting https interception, > > now > > but wasn't when I first encountered this message... > > It can come from many reasons. One has to look at all the clues about > where the message came from, which (if any) server was involved, how > long it took, etc. > > I could write a book on the things and ways it *might* happen. But > whether any of that is relevant or just hand-wavey ideas is anyones > guess at present. > > > From what I know about it currently; corruption HTTP cache entries might > be a side-effect, but very unlikely to be a cause of this. > > Other types of caches used by Squid may be involved, eg the DNS cache > pointing Squid to a server IP that is not responding. But I don't recall > any instances of that data being corrupted, and the duration of the > transaction is far too short to have been some kind of timeout on the > server side of things (immediate TCP reject from invalid server IPs > shows up completely differently.) > > > * ABORTED almost always means the client[1] disconnected from the TCP > connection. That can happen for any number of reasons at the TCP, IP and > Ethernet layers which Squid is not party to. > > ... emphasis on "almost". In the case of CONNECT messages and NTLM > Pinned connections the server can also trigger disconnect for both > endpoints. > > > * HTTPS introduces several additional possible causes. Primarily that > CONNECT message server abort just mentioned. But also if SSL-Bump is > being done, any TLS errors that result in "terminate" action will also > show up as aborts at the TCP and HTTP(S) layers. Squid logging of those > cases has been a bit buggy and there may be issues still yet to be found > there. > That does not explain the pre-HTTPS occurances. But also due to the > vague nature of the abort reason those earlier aborts may be completely > different in cause from your current ones. > > > The "/000" status means no HTTP reply was received from a server. Abort > can also happen any time *after* a server response is received, but > those should be logged with their status codes not 000. > - That may be because no server was even contacted. ie the client > disconnected immediately, or during the wait for server DNS records to > arrive, or for any other reason the client has. > > > SSL-Bump clouds the issue a lot because it will naturally time some > amount of time to do any of its checks and any server contact for server > cert details etc. Again the client can disconnect for any number of > reasons during all that, with the same ABORTED/000 end result. > > > So. Maybe bug, maybe not. "insufficient data". > > > > > > Out of last 5000 requests in my squid log, I see 101 of the > miss_aborted > > statuses. I just wrote a note on stackexchange, then went to look for > > something on amazon (this is output from a squid log compression tool > > that was mostly for listing site, request time and size: A few lines > > from no more than 15 minutes ago (usually shows time between requests, > but > > periodically, there's a full timestamp)... > > > > Part of my shortening process removes the TCP_ before error messages, > > thus my error is just "MISS_ABORTED". > > > > Since this is a grep of that shortened log, the time increments since > > last message are not referring to line immediately above in the grep: > > > > > > [0227_172940.00] 379ms; 0 (0/0) MISS_ABORTED/000 <Athenae [GET > > https://qa.sockets.stackexchange.com/ - 198.252.206.25 -] > > +0.38 372ms; 0 (0/0) MISS_ABORTED/000 <Athenae [GET > > https://qa.sockets.stackexchange.com/ - 198.252.206.25 -] > > +0.01 1ms; 0 (0/0) MISS_ABORTED/000 <Athenae [GET > > https://images-na.ssl-images-amazon.com/images/I/ > 61x0MG3xpeL._AC_UL160_SR160,160_.jpg > > - 54.230.117.34 -] > > +0.00 0ms; 0 (-/-) MISS_ABORTED/000 <Athenae [GET > > https://images-na.ssl-images-amazon.com/images/I/ > 813zL5eetaL._AC_UL160_SR160,160_.jpg > > - 54.230.117.34 -] > > +0.00 0ms; 0 (-/-) MISS_ABORTED/000 <Athenae [GET > > https://images-na.ssl-images-amazon.com/images/I/ > 61Uo2hXZlpL._AC_UL160_SR160,160_.jpg > > - 54.230.117.34 -] > > +0.00 0ms; 0 (-/-) MISS_ABORTED/000 <Athenae [GET > > https://images-na.ssl-images-amazon.com/images/I/ > 71XggjYZ7qL._AC_UL160_SR160,160_.jpg > > - 54.230.117.34 -] > > +0.00 1ms; 0 (-/0) MISS_ABORTED/000 <Athenae [GET > > https://images-na.ssl-images-amazon.com/images/I/71LT8PAs- > OL._AC_UL160_SR160,160_.jpg > > - 54.230.117.34 -] > > +0.00 1ms; 0 (-/0) MISS_ABORTED/000 <Athenae [GET > > https://images-na.ssl-images-amazon.com/images/I/51X+ > 70QICxL._AC_UL160_SR160,160_.jpg > > - 54.230.117.34 -] > > [0227_173215.00] 16ms; 0 (0/0) MISS_ABORTED/000 <Athenae [GET > > https://www.amazon.com/gp/uedata?ul&v=0.200071.0&id= > TXSV6J9MMKFJ764232PB&ctb=1&m=1&sc=TXSV6J9MMKFJ764232PB&pc= > 3758697&tc=-286&hob=1&hoe=3&ul=3758697&t=1519781535329& > csmtags=mouseHit&pty=Detail&spty=Glance&pti=B079GH97R9& > tid=TXSV6J9MMKFJ764232PB&aftb=1 > > - 23.192.244.68 -] > > ==================================== > > > > > > Of note -- a bunch were in trying to fetch a sockets address on > > stackexchange, , while most of the amazon lines seem to be referring to > > jpgs. Anyway, I too would be interested if you find the answer. > > If anyone seeing these is up for some detective work I'm interested in > whether there is any kind of pattern for the real timing between those > lines, and between a failure and previous/next successful transaction to > the same server. > Bonus points for getting the info with port numbers to see if there is > a pattern hidden in the client connection state. > > > While its nice to know the frequency is decreasing (IIRC first reporters > had unpleasantly large amounts, now to this ~2% of yours) that does not > really tell much of use for resolving it (or 'them' if multiple issues). > > > > > > Just thought I'd mention that your seeing the message isn't unique. > > > > Found someone else who asked the same question back in May 2015... > > > > Nod. It has been cropping up since the ABORTED log tag was first added, > and "000" status since long before that. > > Amos > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
