diff --git a/Platform Documentation.md b/Platform Documentation.md index 18dc986..8f2a1eb 100644 --- a/Platform Documentation.md +++ b/Platform Documentation.md @@ -716,11 +716,44 @@ After you have reduced the total number of requests, it's recommended to cache a #### Caching Proxy -The routing tier that is in front of all deployments includes a [Varnish] caching proxy. To use this feature, it is necessary to use the `*.cloudcontrolled.com` subdomain. To have your requests cached directly in Varnish and speed up the response time through this, ensure you have set correct [cache control headers](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html) (`Cache-Control`, `Expires`, `Age`) for the request. Also, ensure that the request does not include a cookie. Cookies are often used to keep state across requests (e.g. if a user is logged in). To avoid caching responses for logged-in users and returning them to other users, Varnish is configured to never cache requests with cookies. - -To be able to cache requests in Varnish for apps that rely on cookies, we recommend using a [cookieless domain](http://www.ravelrumba.com/blog/static-cookieless-domain/). In this case, you have to register a new domain and configure your DNS database with a `CNAME` record that points to your `APP_NAME.cloudcontrolled.com` subdomain `A` record. Then you can update your web application's configuration to serve static resources from your new domain. - -You can check if a request was cached in Varnish by checking the response's *X-varnish-cache* header. The value HIT means the respons was answered directly from the cache, and MISS means it was not. +The routing tier that is in front of all deployments includes a [Varnish] caching proxy. To use this feature, it is necessary to use the `*.cloudcontrolled.com` subdomain. To have your requests cached directly in Varnish and speed up the response time through this, ensure you have set correct [cache control headers](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html) (`Cache-Control`, `Expires`, `Age`) for the request. + +You can check whether a request was cached in Varnish by checking the response's *X-varnish-cache* header. The value HIT means the respons was answered directly from the cache, and MISS means it was not. + +##### Caching Proxy and cookies +Cookies are often used to keep state across requests (e.g. if a user is logged in, shopping cart content, etc.). To avoid caching responses for logged-in users and returning them to other users, Varnish is configured to prevent caching of requests that involve cookies. However, *some* cookies are allowed though, for example those needed for Google Analytics (and other trackers) to function properly. + +To be able to cache requests in Varnish for applications that rely on cookies, either: + +- use a [cookieless domain](http://www.ravelrumba.com/blog/static-cookieless-domain/). In this case, you have to register a new domain and configure your DNS database with a `CNAME` record that points to your `APP_NAME.cloudcontrolled.com` subdomain `A` record. Then you can update your web application's configuration to serve static resources from your new domain. +- name your cookies to match one of the following regular expressions (*use with caution!*), which are used to identify 'allowed' cookies: + - `__[a-z]+` + - `has_js` + - `_ga` + - `_gat_tracker[-a-zA-Z0-9]` + - `varnishCacheIgnore__[a-zA-Z]+` + +Note that the latter option should be handled with great care. A way to strip out all 'outgoing' cookies from responses is to use a .htaccess rule: + + #Do not set any cookies when coming from a .html page, to prevent them from being cached when the .html is generated by the backend + #Note we use FileMatch and not ExpiresByType to prevent HTML output of a PHP script (which typically does not have a URL ending in '.html') is cached + + + ExpiresActive on + ExpiresDefault "modification plus 1 day" + Header append Cache-Control "public" + Header unset Set-Cookie + + + +When you combine this rule with a session cookie that has an 'allowed' name such as `varnishCacheIgnore__applicationNameSession`, this makes it possible to get best of both worlds: + +- cache the content of requests to 'static' content that does not change often (in this example once a day), for example: + - `/catalog.html` + - `/product1.html` +- maintain user sessions by injecting 'dynamic' content using AJAX, for example: + - `/login-status.php` + - `/shoppingcart.php` #### In-Memory Caching