The main reason I can&#39;t just rely on expires times that are included in the individual fragments is to support the Invalidation Spec<br><a href="http://www.w3.org/TR/esi-invp">http://www.w3.org/TR/esi-invp</a><br><br>The use cases for when you would want this kind of invalidation is for times when you have an object that needs to be invalidated.&nbsp; I&#39;m actually in favor of not supporting this case, since IMO you can always store the unique information in the key required to invalidate.&nbsp; But there are some edge cases where invalidating becomes useful...&nbsp; 
<br><br><div><span class="gmail_quote">On 9/10/07, <b class="gmail_sendername">Tres Seaver</b> &lt;<a href="mailto:tseaver@palladion.com">tseaver@palladion.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA1<br><br>Todd Fisher wrote:<br>&gt; Hi all,<br>&gt;<br>&gt;&nbsp;&nbsp; I&#39;ve been working on implementing a ESI (Edge Side Include) Proxy caching<br>&gt; server.&nbsp;&nbsp; The idea is very similar to SSI (Server Side Include), except the
<br>&gt; includes are remote instead of local.<br>&gt;<br>&gt; There&#39;s a very nice write up of using SSI in this context with nginx and<br>&gt; memcached here =&gt;<br>&gt; <a href="http://blog.kovyrin.net/2007/08/05/using-nginx-ssi-and-memcache-to-make-your-web-applications-faster/">
http://blog.kovyrin.net/2007/08/05/using-nginx-ssi-and-memcache-to-make-your-web-applications-faster/</a><br><br>Cool idea:&nbsp;&nbsp;I was the lead for the project which funded adding ESI to<br>squid3, and I&#39;m in favor of multiple implementations.
<br><br>&gt; My project is mongrel-esi (<a href="http://code.google.com/p/mongrel-esi">http://code.google.com/p/mongrel-esi</a>) and I&#39;d<br>&gt; like to use it as an example of how one can use memcache and still<br>&gt; invalidate URLs using regular expressions.
<br>&gt;<br>&gt; The basic idea is to store the regular expressions that have been picked up<br>&gt; by processing an invalidation rule in memcache.&nbsp;&nbsp; Before retrieving a key<br>&gt; from memcache checking if the key matches any of the regular expressions in
<br>&gt; the invalidation-key and that the object being cached is older then the<br>&gt; invalidation rule that matched.&nbsp;&nbsp; We can probably be clever about how we<br>&gt; name the invalidation-key so that it too can expire.&nbsp;&nbsp; So long as the
<br>&gt; invalidation-key doesn&#39;t expire before a predetermined max-expiration time<br>&gt; that all keys get.&nbsp;&nbsp;Then we can be certain that either before we request a<br>&gt; key, or the keys expiration time the objects marked to expire by the regex
<br>&gt; will expire as requested by surrogate.<br>&gt;<br>&gt; For me this realization is great because it means I can finish implementing<br>&gt; the proxy server using memcached as the cache storage.&nbsp;&nbsp; Hopefully, it also
<br>&gt; will be a helpful solution for others looking to access all the keys.&nbsp;&nbsp; And<br>&gt; of course, I may&nbsp;&nbsp;be&nbsp;&nbsp;missing something important, so please correct me if I<br>&gt; have.<br>&gt;<br>&gt; With this solution I think it&#39;s important to get the clever part about
<br>&gt; making sure the expire rules have an expire time on them that is greater<br>&gt; then or equal to the expire time of all keys.&nbsp;&nbsp;There may also be some ways<br>&gt; to name the keys based on the specific domain to have more then one
<br>&gt; invalidation key to avoid letting it grow into a large dataset that needs to<br>&gt; be retrieved everytime.&nbsp;&nbsp; It also means you have two hits on memcache per<br>&gt; key lookup instead of the one before...&nbsp;&nbsp; There are probably other
<br>&gt; techniques for solving this problem...&nbsp;&nbsp;Just hoping it makes sense and is<br>&gt; useful to others...<br><br>I&#39;m puzzled:&nbsp;&nbsp;why don&#39;t you store the fragments into memcache using<br>expiration times which correspond to the HTTP cache headers which
<br>wrapped them?&nbsp;&nbsp;One of the reasons I was excited about ESI was that I<br>could cache different sections of the page with different policies,<br>which meant I could drop the whole idea of purging pages from the Squid<br>
cache:&nbsp;&nbsp;the &quot;hot&quot; sections of the page would just time out naturally.<br>Most pages themselves would have *long* expiration times, in this<br>scenario (e.g., 1 day);&nbsp;&nbsp; a given zone on the page (e.g., &quot;top 5 news
<br>stories&quot;) might have a very short expiration (e.g., 30 seconds).<br><br><br>Tres.<br>- --<br>===================================================================<br>Tres Seaver&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+1 540-429-0999&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="mailto:tseaver@palladion.com">
tseaver@palladion.com</a><br>Palladion Software&nbsp;&nbsp; &quot;Excellence by Design&quot;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://palladion.com">http://palladion.com</a><br>-----BEGIN PGP SIGNATURE-----<br>Version: GnuPG v1.4.6 (GNU/Linux)<br>Comment: Using GnuPG with Mozilla - 
<a href="http://enigmail.mozdev.org">http://enigmail.mozdev.org</a><br><br>iD8DBQFG5VAi+gerLs4ltQ4RAvheAJ4zpfI6sdcpRm7ZMZDfE08DuNl9UgCeLwXI<br>ivd4FE5pyvC4isPO7/OtVcw=<br>=6TD/<br>-----END PGP SIGNATURE-----<br></blockquote>
</div><br>