Re: Long response header problem

mån 2008-04-21 klockan 21:35 +0200 skrev Axel Westerhold:

> --- src/http.cc 2008-04-01 13:54:38.000000000 +0200
> +++ src/http.cc 2008-04-21 19:11:47.000000000 +0200
> @@ -1200,7 +1200,7 @@
> void
> HttpStateData::maybeReadVirginBody()
> {
> - int read_sz = replyBodySpace(readBuf->spaceSize());
> + int read_sz = replyBodySpace(readBuf->potentialSpaceSize());
>
> debugs(11,9, HERE << (flags.do_next_read ? "may" : "wont") <<
> " read up to " << read_sz << " bytes from FD " << fd);
>

Ok, that's a quite different change. But still not right. See below.

> spaceSize will only return the size left from initial size. This will result
> in read_sz<2 and return some lines down in http.cc.
>
> PotentialSpaceSize will return max_capacity - terminatedSize which seems
> more logical.

No it's not. We do not want this buffer to grow unless absoultely
needed. The upper limit on buffer size is just a safe guard to make sure
something realize when things run completely out of bound.

Regarding how it handles long headers, look a few lines down... it only
returns there if the header has been parsed. If the header has not yet
been parsed it allows the buffer to grow by reading at least 1024 octets
more..

    if (read_sz < 2) {
        if (flags.headers_parsed)
            return;
        else
            read_sz = 1024;
    }

But there is one cosmetic problem here in that we log the expected read
size before adjustment, with the adjustment being silent in debug logs..

Regards
Henrik
Received on Tue Apr 22 2008 - 13:31:41 MDT