diff --git a/modules/authcache_varnish/example.vcl b/modules/authcache_varnish/example.vcl
index 180917b..9da1ab6 100644
--- a/modules/authcache_varnish/example.vcl
+++ b/modules/authcache_varnish/example.vcl
@@ -540,9 +540,23 @@ sub vcl_deliver {
     set resp.http.Vary = regsub(resp.http.Vary, "^,\s*", "");
   }
 
+  // When checking whether it is possible to send a 304 instead of a full 200
+  // response, Varnish does not respect the cache-characteristics of embedded
+  // ESI fragments. In order to make this work it would be necessary to merge
+  // all Last-Modified and ETag response headers of all ESI fragments and
+  // generate a new value which is then delivered to the browser. Better 304
+  // support has been on the ESI wishlist for some time but it did not happen
+  // until now.
+  // @see https://www.varnish-cache.org/trac/wiki/Future_ESI
+  //
+  // Disable HTTP revalidation when a page contains ESI fragments.
+  if (resp.http.X-Authcache-Do-ESI) {
+    unset resp.http.ETag;
+    unset resp.http.Last-Modified;
+  }
+
   // Remove variables placed on backend response.
   unset resp.http.X-Authcache-Do-ESI;
-  unset resp.http.X-Authcache-Ban-Tag;
 
   /* END required authcache key-retrieval logic */