[squid-dev] [PATCH] Non-HTTP bypass

[Tsantilas Christos]

On 10/21/2014 04:29 PM, Amos Jeffries wrote:
> 2) All changes in src/tunnel.cc seem to be needless.

Some changes are required!

>   - tunnelStartShovelling() should *always* be the entrypoint to begin
> transmit on a tunnel in any direction. At that point there is maybe
> client data to send to server ...

Yes.

>   - The socket may not even permit one whole TCP_RCV_BUF worth of bytes
> to be written in a single action. comm_write can handle that just fine.
> If comm_write is unable to handle all the available conn->in.buf in one
> comm_write() call then that would be a bug in comm to fix separate from
> all this.

This is true. However we are using two buffers to read/write to/from 
server/client. The TunnelState::client::buf and TunnelState::server::buf 
which are of size SQUID_TCP_SO_RCVBUF

At early stages of this patch I tried to convert these buffers to SBufs 
, but required many changes in the tunnel.cc code, so I revert the 
changes and finally implemented the  TunnelStateData::copyClientBytes 
member.

>   There is simply no reason to add an extra if
> (preReadClientData.length()) conditional in *every* packet I/O cycle.


As you can see the old code copies the ConnStateData::in->buf data to 
TunnelStateData->client.buf buffer. This is because in the case you are 
read a CONNECT request you can be sure that the extra bytes you read are 
not hugger than the SQUID_TCP_SO_RCVBUF.

But for this patch imagine the case where:
   - Squid configured with:
        request_header_max_size 70kbs
   - Client sends something which looks like an HTTP request eg:
         AMETHOD [spaces]* string [spaces]* ... Other data
     Also assume that this is more than the size of 70k.
   - Squid will read 70k before decide that this is not an HTTP request.
   - The 70k are not fit to TunnelStateData->client.buf

An alternate solution is to add some code to build/fix 
TunnelStateData->client.buf to have the required size.
I need to recheck, but looks a good solution.
Is it ok?

>
> Cheers
> Amos
>