[squid-dev] [PATCH] Non-HTTP bypass
chtsanti at users.sourceforge.net
Wed Oct 22 08:12:55 UTC 2014
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 ...
> - 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
> 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:
- 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?
More information about the squid-dev