Re: Long response header problem

Ok,

Did some additional checks,

It should be

 --- 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( SQUID_TCP_SO_RCVBUF, SQUID_TCP_SO_RCVBUF);
      orig_request = HTTPMSGLOCK(fwd->request);
 
      if (fwd->servers)

Which is btw. the coding used in ICAP where SQUID_TCP_SO_RCVBUF = 16384

Regards,
Axel

> 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