> Hmm.. can't seem to reproduce this.
>
> The proposed change do not fix the problem, just hides it a bit.
See my last mail of three (:-) sorry Not my best day)
>
> The 3.0.STABLE4 code already bumps the read size to 1KB minimum when
> headers haven't been successfully parsed yet. See
> HttpStateData::maybeReadVirginBody()
>
> Do you have an example URL triggering the problem?
Yes and no. The Url is including a authentication dialog I can't give you
the username and password for. I'll check if I can come up with something
similar.
>
> Are you using ICAP?
ICAP is off for this test.
>
> Any other interesting details about your configuration?
Nothing special. Actually the bug showed up on STABLE1 and I tested with a
STABLE4 without modifications (failed) patched with the longresp patch
(failed).
>
> Regards
> Henrik
>
As said, see my third mail:
----SNIP
--- 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);
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.
---SNIP
Regards,
Axel
