Re: Squid-3 and large response headers

From: Alex Rousskov <rousskov@dont-contact.us>
Date: Wed, 09 Jan 2008 08:15:34 -0700

On Wed, 2008-01-09 at 09:55 +0100, Henrik Nordström wrote:
> tis 2008-01-08 klockan 23:39 -0700 skrev Alex Rousskov:
>
> > The ICAPXaction::readBuf data member stores incoming headers. It is
> > initialized as follows:
> >
> > readBuf.init(SQUID_TCP_SO_RCVBUF, SQUID_TCP_SO_RCVBUF);
>
> Ok. So it should then be limited to TCP_SO_RCVBUF before seeing the same
> problem. Better than the 4k limit seen elsewhere, but still a problem.
>
> The problem in the HTTP server-side client code was that it never
> allowed the buffer to grow to make room for the full response header.

My understanding is that you can replace the second SQUID_TCP_SO_RCVBUF
constant with a larger one to allow the buffer to grow. No other changes
should be needed except taking care of this assertion:

> // make sure maximum readBuf space does not exceed commBuf size
> Must(static_cast<size_t>(readBuf.potentialSpaceSize()) <= commBufSize);

It may be a good time to eliminate commBuf completely to avoid the
problem.

I may be missing some subtle dependencies though. You can probably check
my understanding by replacing the above buffer initialization with
something like

    readBuf.init(1, SQUID_TCP_SO_RCVBUF);

to force ICAP to grow the buffer as needed.

If we start increasing the upper limits, we may want to start
calculating the total allocated buffer space to restrict buffer growth
to avoid DoS attacks.

Alex.
Received on Wed Jan 09 2008 - 08:15:44 MST

This archive was generated by hypermail pre-2.1.9 : Wed Jan 30 2008 - 12:00:09 MST