I would like to pass the varnish cache if some certain session variable is present.
I.e.: if the user has a session variable named foo, I would like to have Varnish fetch the content from the origin instead of delivery the cached version.
Related
I'm missing something trying to understand cache-control (e.g., from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control).
How do I set up cache control to accomplish the following (I'll be using an .htaccess file):
If client fetches a file, it should always store it in the cache.
When client needs a file, it should always check to see if the file has been changed and download a new copy if it has changed.
If the attempt to check fails -- e.g., server down or no Internet connection -- client should always use a cached copy if available, no matter how old. Any copy is better than none.
Use Cache-Control: no-cache and set the ETag header.
The resource will be stored in the cache. This is true of any cache header other than no-store.
no-cache tells the client that it must check with the server to see if the cached copy is valid. It does this by sending a conditional request, which requires that the cached response have an ETag (or Last-Modified) header.
Using a cached copy of a resource when there's no connectivity is the default behavior. You could prevent this with the must-revalidate directive.
Context
I have a distribution where I added the host to the cache policy
These 2 domains point to the same distribution:
www.site1.com/pageA
www.site2.com/pageA
these 2 hosts have their respective cache entry, In this setup, I have a custom origin response lambda on edge that will return different content base on the host.
The question:
I'm use to invalidate based on the path ex: /pageA
how should I format my invalidation if I want to only invalidate pageA for site1?
It is currently not possible to invalidate by domain.
Cloudfront invalidation is by path only.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
If I set maxAge when I called sendFile(), just like below:
res.sendFile('public/index.html', {maxAge: 100000})
Does this mean the file 'public/index.html' will cached in server's memory for 100 seconds? Or, This is just a message send to client side, and server side's does nothing with memory cache?
maxAge is a directive for the Cache-Control header. In your case, this tells the client that index.html will be considered 'fresh' for 100000ms, so it is unnecessary to ask the server again for that file until maxAge has elapsed. The client keeps this file for the duration, it has nothing to do with server caching.
However, who caches what does depend on which way the directive is going.
As stated on MDN:
max-age=
Specifies the maximum amount of time a resource will be considered fresh. Contrary to Expires, this directive is relative to the time of the request.
And
The Cache-Control general-header field is used to specify directives for caching mechanisms in both requests and responses. Caching directives are unidirectional, meaning that a given directive in a request is not implying that the same directive is to be given in the response.
In some situations when my application responds with 404 Not Found code it also returns Set-Cookie directive with session identifier, but there is no Cache-Controle or Pragma directive. Does this mean that session identifier can be stored in browser cache and does this influence the security of the application? I am not sure if all responses with Set-Cookie should contain caching directives.
Whether a cookie is permanently stored in the browser or not is controlled by the Expires and Max-Age properties. Cache-Control and Pragma headers only affect page contents. So I think you're good on 404 pages even without explicit cache headers (* but see the edit below).
Session cookies should always be set without an explicit expiry date, in which case they won't normally be stored on disk and will be removed when the user quits the browser.
(Note that there are cases beyond your control when such data from memory will still be persisted to disk, like for example when a user decides to hibernate, or the computer runs out of memory and starts to swap.)
Edit (see comments):
In case of normal pages that set cookies, you usually have headers to prevent caching of sensitive info like Cache-control: no-cache,no-store,must-revalidate. This I think inherently includes not caching cookie responses either, so you don't need to explicitly set it on normal pages.
So the question is then, what cookie is set on a 404 page? If an unauthenticated user downloads the 404 page and gets a session cookie, that cookie is useless for an attacker, as the application should not be vulnerable to session fixation (the cookie value should change upon logon anyway). If it is an authenticated user, why would the application set the session cookie again on a 404 page? If it does though, you should send headers to prevent caching, that's a good catch by Skipfish. (In fact, you can do this for unauthenticated users too, but I would rate that a very low risk.)
I have a very simple site and am setting up varnish cache on it. The server is nginx.
The cache seems to get automatically purged after 120 seconds as when I go on the site i see the Age header being reset.
Can anyone point me towards where to remove this and have pages cached indefinitely or until i manually purge varnish?
You did not mention your OS or distribution, but for example on CentOS /etc/sysconfig/varnish sets the defaults for Varnish. Amongst those defaults is VARNISH_TTL=120, which sets the default TTL to 120 seconds.
If you only wish to set a high TTL for all objects, you can just edit the default one in /etc/sysconfig/varnish.
If the backend sends to the Varnish age headers, the Varnish will consider them as a real expiration date just like a web browser and will purge it's content when the header expires.
You should make sure that the backend doesn't send cache-control headers to the varnish and only the varnish will add cache-control headers when sending data to the browsers.