Varnish computes Content-Length and set it to 0 for one of my URL!

[Michael Alger]

On Fri, Aug 06, 2010 at 03:17:10PM +0200, zabrane Mikael wrote:
> But the problem can be easily reproduced. Here's an example:
> $ cat bug.vcl
> backend squid {
>   host = "127.0.0.1";
>   port = "3128";
> }
> backend cache {
>   .host = "127.0.0.1";
>   .port = "7676";
> }
> 
> 1) suppose squid is up and running, and used as a Varnish backend
> # /etc/init.d/squid start
> 
> 2) start Varnish:
> # varnishd -n foo -f bug.vcl -s malloc,512M -a :6081
> storage_malloc: max size 512 MB.
> Using old SHMFILE
> 
> 3) Test with CURL:
> 3.1) Getting resource directly from live web without Varnish :
> 
> HTTP/1.0 200 OK
> [no content-length header]
> 
> 3.2) Using CURL through Squid (without varnish) :
> 
> HTTP/1.0 200 OK
> [no content-length header]
> 
> 3.3) Now, using Varnish :
> $ curl -0 -v -I --no-keepalive --proxy 127.0.0.1:6081 http://www.groupama.fr/
> 
> HTTP/1.1 200 OK
> [no content-length header]
> 
> Notice that for scenario 3.2, Squid replies with HTTP/1.0 (as
> requested by "curl -0").
> For scenario 3.3, Varnish reply with HTTP/1.1.

I don't think is likely to be relevant, and merely indicates that
squid doesn't support HTTP/1.1.

RFC 2145:

   An HTTP server SHOULD send a response version equal to the
   highest version for which the server is at least conditionally
   compliant, and whose major version is less than or equal to the
   one received in the request.

and RFC 2616:

   Due to interoperability problems with HTTP/1.0 proxies discovered
   since the publication of RFC 2068, caching proxies MUST, [...]
   upgrade the request to the highest version they support.

Squid's HTTP/1.0 response suggests that it doesn't support HTTP 1.1.

> In my first email pointing out this bug,
> our caching backend (running on port 7676) replies correctly:
> 
> $ curl -0 -v -I --no-keepalive --proxy 127.0.0.1:7676 http://www.groupama.fr/
> [no content-length header]
> 
> Finally, accessing our caching backend through Varnish failed
> (notice the Content-Length: 0):
> $ curl -0 -v -I --no-keepalive --proxy 127.0.0.1:6081 http://www.groupama.fr/
> 
> Content-Length	0

Have you examined the response from your caching backend and
compared it to the direct response, or the response from squid? It
seems like Varnish is only adding the erroneous header when it is
using your "caching backend", yes? (i.e. the thing on port 7676)

Would capturing the traffic Varnish sees with tcpdump and comparing
the two (squid and the caching backend) be feasible?

Does Varnish also have this behaviour if it fetches the data
straight from the source server, or is it only present if it fetches
it via the caching backend?