[squid-users] TCP_TUNNEL_ABORTED/200?

[Alex Rousskov]

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.