Long response header problem

Hi there,

I ran, or better a customer ran into a problem today which sounded like this
bug.

http://www.squid-cache.org/bugs/show_bug.cgi?id=2001

So I applied the attached patch to squid-3.0.STABLE4 and did a quick test.
Still the same problem. By cache.log looks like this

...
comm_read_try: FD 16, size 4094, retval 2896, errno 0
...
HttpMsg::parse: failed to find end of headers (eof: 0)
...
http.cc(1050) needs more at 2896
http.cc(1206) may read up to 1199 bytes from FD 16
...
comm_select(): got FD 16 events=1 monitoring=19 F->read_handler=1
F->write_handler=0
comm_select(): Calling read handler on FD 16
comm_read_try: FD 16, size 1198, retval 1198, errno 0
...
HttpMsg::parse: failed to find end of headers (eof: 0)
...
http.cc(1050) needs more at 4094
http.cc(1206) may read up to 1 bytes from FD 16
...
comm_select(): got FD 16 events=1 monitoring=19 F->read_handler=0
F->write_handler=0
comm_select(): no read handler for FD 16

and so on and so on. So I checked the coding in http.cc and changed it as
follows.

--- src/http.cc 2008-04-01 13:54:38.000000000 +0200
+++ src/http.cc 2008-04-21 16:42:19.000000000 +0200
@@ -75,7 +75,7 @@
     surrogateNoStore = false;
     fd = fwd->server_fd;
     readBuf = new MemBuf;
- readBuf->init(4096, SQUID_TCP_SO_RCVBUF);
+ readBuf->init(16384, SQUID_TCP_SO_RCVBUF);
     orig_request = HTTPMSGLOCK(fwd->request);

     if (fwd->servers)

Now it works but I am not sure if a.) this is a good solution and b.) a
stable one :-).

Maybe someone with more knowledge can do a check.

Regards,
Axel Westerhold
DTS Systeme GmbH
Received on Tue Apr 22 2008 - 13:48:07 MDT