Varnish 3 has introduced a new behavior wherein it will always try to request items from a backend with Accept-Encoding: gzip. I'm seeing that on the first request per file when agrcache is enabled, Varnish doesn't like the response it receives and bombs out with the following message: "incorrect header check". Varnish then sends a 503 to the browser.

Subsequent requests are fine.

I'll take a deeper look later on, but wanted to report it regardless.

Comments

edu2004eu’s picture

Hello,

Have you found a workaround for this issue? I'm struggling to eliminate it on a production server and simply can't.

jeffsheltren’s picture

I haven't been able to reproduce this -- I'm testing with Varnish 3.0.3 using the default VCL and agrcache 7.x-1.1. It might help to share some log entries and potentially your VCL.

erikwebb’s picture

Issue summary: View changes

I think I'm seeing something similar (from varnishlog) -

44 VCL_return c deliver
44 ObjProtocol c HTTP/1.1
44 ObjResponse c OK
44 ObjHeader c Server: nginx
44 ObjHeader c Date: Mon, 17 Mar 2014 12:35:23 GMT
44 ObjHeader c Content-Type: text/html
44 ObjHeader c X-Drupal-Cache: MISS
44 ObjHeader c Etag: "1395059723-1"
44 ObjHeader c Content-Language: en
44 ObjHeader c Cache-Control: public, max-age=32140800
44 ObjHeader c Last-Modified: Mon, 17 Mar 2014 12:35:23 +0000
44 ObjHeader c Expires: Sun, 19 Nov 1978 05:00:00 GMT
44 ObjHeader c Vary: Cookie,Accept-Encoding
44 ObjHeader c Content-Encoding: gzip
44 Gzip c u F - 0 0 0 0 0
44 FetchError c TestGunzip error at the very end
44 VCL_call c error deliver
44 VCL_call c deliver deliver
44 TxProtocol c HTTP/1.1
44 TxStatus c 503
44 TxResponse c Service Unavailable
44 TxHeader c Server: Varnish
44 TxHeader c Content-Type: text/html; charset=utf-8
44 TxHeader c Content-Length: 555
44 TxHeader c Accept-Ranges: bytes
44 TxHeader c Date: Mon, 17 Mar 2014 12:35:23 GMT
44 TxHeader c X-Varnish: 2142411413
44 TxHeader c Age: 0
44 TxHeader c Via: 1.1 varnish
44 TxHeader c Connection: close
44 TxHeader c X-Cache: MISS
44 Length c 555

erikwebb’s picture

Title: First request sends invalid gzipped data, causing Varnish 3.0.2 to 503 » First request sends invalid gzipped data, causing Varnish 3 to 503
erikwebb’s picture

I haven't tracked down how this is happening within Drupal, but here is a method for solving the problem through Varnish - https://www.varnish-cache.org/lists/pipermail/varnish-misc/2013-July/023...

if (beresp.http.Content-Encoding ~ "gzip" ) {
   if (beresp.http.Content-Length == "0") {
        unset beresp.http.Content-Encoding;
   }
}
mcdruid’s picture

This is probably not the same issue, but as our searching for the error message led us here...

We were seeing Varnish return a 503 along these lines:

   57 FetchError   c Invalid Gzip data: incorrect header check
   57 Gzip         c u F - 2 0 0 0 0
   57 VCL_call     c error deliver
   57 VCL_call     c deliver deliver
   57 TxProtocol   c HTTP/1.1
   57 TxStatus     c 503
   57 TxResponse   c Service Unavailable
   57 TxHeader     c Server: Varnish

This turned out to be due to whitespace outside the PHP tags in settings.php which was being output before headers. So a very simple fix, but not necessarily the first thing you'd think of with that error message from Varnish.

catch’s picture

Status: Active » Closed (duplicate)

This is probably fixed by #2628874: Don't send cacheable headers from the menu callback (just committed to dev). Please re-open if it's not.