Re: Long response header problem

Axel Westerhold wrote:
>> 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
>>
> Uhmmm,
>
> See my mybeReadVirginBody() from Stable4
>
> Any chance that you re using CVS ?

Do you mean you want CVS access?
We use Bazaar for Squid-3. Details:
   http://wiki.squid-cache.org/Squid3VCS

Or rsync has the latest patched source:
   rsync -avz rsync://squid-cache.org/source/squid-3.0

Amos

-- 
Please use Squid 2.6.STABLE19 or 3.0.STABLE4