> 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
>
Mmmh ok,
but why does my change solve the problem ? What it does is, it allows the
complete header to be read in one operations. Before there were at least
three reads before it stopped with 4094 read, one byte left and then it
stopped.
http.cc(1050) needs more at 4094
http.cc(1206) may read up to 1 bytes from FD 16
There might be another check somewhere not allowing the header to grow above
4096 Bytes or doing so within a specific number of reads.
I'll check into this tommorow at work.
Regards,
Axel
Received on Tue Apr 22 2008 - 13:17:36 MDT
This archive was generated by hypermail 2.2.0 : Wed Apr 30 2008 - 12:00:07 MDT