Re: Long response header problem

From: Axel Westerhold <ml.awesterhold@dont-contact.us>
Date: Tue, 22 Apr 2008 06:49:45 +0200

> 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;
>>> }
>>>
Hi Amos,

Thanks for your reply, but no. I actually was just wondering why my STABLE4
code looked different then the one Henrik was refering too.

So I thought Henrik might use some CVS code for testing. It simply took some
time for me to realise that he, correctly, was using the patched code
(longresp patch) and I didn't :-).

Over all it seems I did make a good amount of mistakes yesterday when
checking what a customer of mine was reporting as a bug.

My apologize again for my flood of mails.

Regards,
Axel

>>>
>>> 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
Received on Tue Apr 22 2008 - 12:51:34 MDT

This archive was generated by hypermail 2.2.0 : Wed Apr 30 2008 - 12:00:07 MDT