On 08/31/2016 08:25 AM, Amos Jeffries wrote: > On 31/08/2016 8:20 p.m., Ralf Hildebrandt wrote: >> I can't find anything on what exactly would cause a >> "TCP_TUNNEL_ABORTED/200" > A client that disconnects before the server has finished sending data, If "has finished sending" means "closed connection", then I do not think that should trigger the _ABORTED suffix. If it does, it is a Squid bug IMO. When tunneling, Squid should not assume that the server must close the connection first. > or before Squid has relayed the data it sent to the server. That too should not trigger an _ABORTED suffix IMO, for similar reasons. In general, nothing prevents Squid from relayed client data to the server after the client has disconnected (or vice versa). AFAICT, the tunnel code should add an _ABORTED suffix only if Squid has data destined for an already closed connection. I did not check whether the code actually obeys that, and the answer may be version-specific. To make matters more complex, there are also so called half-closed TCP connections. IIRC (and that is a big IF!), the tunneling code is one of the areas where Squid does not handle them correctly. If my recollection is correct, and the tunneled applications half-close, then Squid may break those applications. > The TUNNEL and 200 parts means Squid connected to the requested server. > The ABORTED that the client disconnected while tunnel data was still in > transit. Agreed, provided "data in transit" means "Squid-buffered bytes not yet sent to that already-disconnected client". Cheers, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
