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
