<div dir="ltr">Hi, I've enabled varnish ESI processing on a config that handles public domains passing through akamai, I've noticed that origin(varnish) is returning a 304 to akamai which then revalidates the object and passes stale content to the client, though ESI content has been modified, properly parsed and visible on the origin domains.<div><div><br></div><div>running on varnish-3.0.6 revision 1899836<br><div><br></div><div>based on some tests, this not so elegant piece of vcl seems to solve the issue, setting defaul TTL to 2mins @ akamai and updating content served by ESI's, i've not seen any ESI content older than 2mins being served. </div><div><br></div><div> if (beresp.status == 200 && beresp.http.X-ADI-NSAPP == "ssf" && beresp.http.Content-type ~ "html") {</div><div>               set beresp.http.Last-Modified = beresp.http.date;</div><div>                unset beresp.http.X-ADI-NSAPP; </div><div><br></div><div><br></div><div>if i removed that piece of code from my config, my ESIs go stale.</div><div><br></div><div>this is what my headers look like with and without the above piece of vcl </div><div><br></div><div><br></div><div><b>without  </b>beresp.http.date <b>:</b></div><div><br></div><div>







<p class="">HTTP/1.1 200 OK</p><p class="">Server: Apache</p><p class=""><b>Last-Modified: Thu, 26 Feb 2015 14:21:06 GMT</b></p><p class="">ntCoent-Length: 7536</p><p class="">Cache-Control: max-age=1</p><p class="">Expires: Fri, 06 Mar 2015 13:41:28 GMT</p><p class="">Content-Type: text/html; charset=UTF-8<br></p><p class="">X-ADI-NSAPP: ssf</p><p class="">X-ADI-Backend: default</p><p class="">Date: Fri, 06 Mar 2015 13:41:27 GMT</p><p class="">X-Varnish: 1539216520</p><p class="">Age: 0</p><p class="">Via: 1.1 varnish</p><p class="">Connection: keep-alive</p><p class=""><br></p><p class=""><b>with </b>beresp.http.date  <b>:</b></p><p class="">HTTP/1.1 200 OK<br></p><p class="">Server: Apache</p><p class="">ntCoent-Length: 7536</p><p class="">Cache-Control: max-age=1</p><p class="">Expires: Fri, 06 Mar 2015 13:40:03 GMT</p><p class="">Content-Type: text/html; charset=UTF-8<br></p><p class="">X-ADI-Backend: default</p><p class=""><b>Last-Modified: Fri, 06 Mar 2015 13:40:02 GMT</b></p><p class="">Date: Fri, 06 Mar 2015 13:40:02 GMT</p><p class="">X-Varnish: 1125382905</p><p class="">Age: 0</p><p class="">Via: 1.1 varnish</p><p class="">Connection: keep-alive</p><p class="">a helpful friend passed along this possible solution. <br></p></div><div><br></div><div><a href="https://www.varnish-cache.org/lists/pipermail/varnish-commit/2009-June/004322.html">https://www.varnish-cache.org/lists/pipermail/varnish-commit/2009-June/004322.html</a><br></div><div><a href="https://www.varnish-cache.org/trac/changeset/c64a6482f235a4f27e830d609c9a102c716d0bc6">https://www.varnish-cache.org/trac/changeset/c64a6482f235a4f27e830d609c9a102c716d0bc6</a><br></div><div><br></div><div>this seems like a much more nicer way of handling ESI LM headers. any suggestions for properly handling LM for ESIs or a way to test and implement the above patch committed in 2009, would be most welcomed.<br></div><div><br></div><div><br></div><div><br></div><div>kind regards</div><div>-LC<br> </div><div><br></div><div><br></div><div><br></div></div></div></div>