Re: Long response header problem

From: Axel Westerhold <ml.awesterhold@dont-contact.us>
Date: Mon, 21 Apr 2008 21:35:45 +0200

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

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