In your varnishlog, you may see the following error appearing.
11 ObjProtocol c HTTP/1.1 11 ObjResponse c OK 11 ObjHeader c Content-Length: 482350 ... 11 FetchError c straight insufficient bytes 11 Gzip c u F - 437646 482350 80 3501088 3501098 11 VCL_call c error deliver 11 VCL_call c deliver deliver 11 TxProtocol c HTTP/1.1 11 TxStatus c 503 11 TxResponse c Service Unavailable 11 TxHeader c Accept-Ranges: bytes
When you check the access logs on your backend server, you may notice something odd about the Content-Length header. For instance, here’s an access logs from my backend webserver.
... "GET /some/file.pdf HTTP/1.1" 200 437646 "referer" "user-agent"
The access logs show the size of the request is 437646 bytes, whereas Varnish thinks the request is 482350 bytes (Content-Length header). So the “straight insufficient bytes” literally means: the response I got from the backend did not contain enough bytes, I was expecting more. I’ll panic now, kthxbye.
The backend indicated the request was 482KB in size, but it only sent along 437KB according to the logs. No wonder Varnish freaks out.
There’s no real fix, though, except to make sure your backend sends along as much bytes to Varnish as it indicates with the Content-Length header. There are odd cases where Gzip/Deflate compression can screw up these numbers, if you’re debugging this – disable the gzip compression or mod_deflate in Apache and try again. See if it helps. If so, you’re on the right track and you may be experiencing mod_fastcgi + mod_deflate combination errors.
Alternatively, you can return (pipe); those requests. A piped request won’t do extensive checks on what the backend responds and just pass everything to the client as-is.