<div>Hi,</div><br><div>I'm trying to understand whether it's feasible to build a CDN of Varnish instances, whose primary origin(backend) is a  Varnish instance which processes an ESI-capable app.</div><br><div>So basically:</div><br><div>USA visitor -> Varnish USA -> Varnish primary -> THE APP with ESI blocks</div><div>RUS visitor -> Varnish RUS -> Varnish primary -> THE APP with ESI blocks</div><div>CAN -> Varnish primary -> THE APP with ESI blocks</div><br><div>The APP emits HTML with ESI tags for different blocks, and sure enough, those have different cache policies.</div><div>If a request arrives to an edge Varnish, I want it to talk to the primary Varnish  (so as to cache on the edge against a primary cache), but this "Varnish primary" serves the content with ESI already assembled. Thus there is no telling, how long we should cache that full page HTML on the edges.</div><br><div>Q: Is there a magic way to instruct the primary Varnish to not do ESI processing on the content that was <em>already cached</em> ??</div><div>Meaning keep things as usual if request arrives directly to primary Varnish (ESI on), but receive non-assembled HTML (with esi tags inside) otherwise, so that edges can do assembling themselves, and thus cache things on the edge with proper TTLs for blocks.</div><br><div>Or I just have to resort to completely disabling do_esi on the primary server? Which I could do, but that must mean that the primary Varnish cannot serve visitors directly (= loosing the edge location with lowest latency to nearby users).</div><br>