Re: Fix incorrect Last-Modified from backend?
On Thu, Mar 19, 2020 at 09:57 AM Dridi Boukelmoune wrote: > > By the way, when it comes to revalidation based on the body, you > should use ETag instead of Last-Modified. Sadly, there is no ETag available. And I can't see any way of adding it without "hacking" the software (patching their code in an unsupported way, causing problems every time we want to upgrade that software). But I'm waiting for a reply on a support case I created, asking about this. But if I had easy access to the body in Varnish this would be "trivial" to implement there. ___ varnish-misc mailing list varnish-misc@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Re: Fix incorrect Last-Modified from backend?
On Wed, Mar 18, 2020 at 2:17 PM Batanun B wrote: > > Hi, > > Long story short, one of our backend systems serves an incorrect > Last-Modified response header, and I don't see a way to fix it at the source > (third party system, not based on Nginx/Tomcat/IIS or anything like that). > > So, I would like to "fix" it in Varnish, since I don't expect the maker of > that software being able to fix this within a reasonable time. Is there a > built in way in Varnish to make it generate it's own Last-Modified response > header? Something like: > > * If no stale object exists in cache, set Last-Modified to the value of the > Date response header > * If a stale object exists in cache, and it's body content is identical to > the newly fetched content, keep the Last-Modified from the step above > * If a stale object exists in cache, but it's body content is different to > the newly fetched content, set Last-Modified to the value of the Date > response header I don't think you can do something like that without writing a module, and even if you could you would still have a chicken-egg problem for streaming deliveries when it comes to generating a header based on the contents of the body (you would need trailers, but we don't support them). By the way, when it comes to revalidation based on the body, you should use ETag instead of Last-Modified. > Any suggestions on how to handle this situation? Any general Varnish > guidelines when working with a backend that acts like this? I think that's a tough nut to crack. There are many things you can work around from a misbehaving backend but this case is not trivial. Dridi ___ varnish-misc mailing list varnish-misc@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
Fix incorrect Last-Modified from backend?
Hi, Long story short, one of our backend systems serves an incorrect Last-Modified response header, and I don't see a way to fix it at the source (third party system, not based on Nginx/Tomcat/IIS or anything like that). So, I would like to "fix" it in Varnish, since I don't expect the maker of that software being able to fix this within a reasonable time. Is there a built in way in Varnish to make it generate it's own Last-Modified response header? Something like: * If no stale object exists in cache, set Last-Modified to the value of the Date response header * If a stale object exists in cache, and it's body content is identical to the newly fetched content, keep the Last-Modified from the step above * If a stale object exists in cache, but it's body content is different to the newly fetched content, set Last-Modified to the value of the Date response header Any suggestions on how to handle this situation? Any general Varnish guidelines when working with a backend that acts like this? Regards ___ varnish-misc mailing list varnish-misc@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
