From 3881e4f4e0f402f6d0f37077e54b11bbd450d9de Mon Sep 17 00:00:00 2001 From: Menno Holtkamp Date: Thu, 21 May 2015 22:18:33 +0200 Subject: [PATCH 1/2] Added section about cookies 'allowed' by Varnish --- Platform Documentation.md | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/Platform Documentation.md b/Platform Documentation.md index 18dc986..f326b3f 100644 --- a/Platform Documentation.md +++ b/Platform Documentation.md @@ -716,11 +716,36 @@ 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. +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. -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 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. -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. +##### 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 the ones neede for Google Analytics 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 the following .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 + + #### In-Memory Caching From fb55c811e7be9c01d337a540fbf7f851e8cee4f5 Mon Sep 17 00:00:00 2001 From: Menno Holtkamp Date: Thu, 21 May 2015 22:35:49 +0200 Subject: [PATCH 2/2] Included examples of static and dynamic content --- Platform Documentation.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/Platform Documentation.md b/Platform Documentation.md index f326b3f..8f2a1eb 100644 --- a/Platform Documentation.md +++ b/Platform Documentation.md @@ -721,20 +721,19 @@ The routing tier that is in front of all deployments includes a [Varnish] cachin 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 the ones neede for Google Analytics to function properly. +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 the following .htaccess rule: + - `__[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 @@ -747,6 +746,15 @@ Note that the latter option should be handled with great care. A way to strip ou +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 To speed up requests that can't use a cookieless domain, you can use in-memory caching to store arbitrary data from database query results to complete http responses. Since the cloudControl routing tier distributes requests across all available containers, it is recommended to cache data in a way that the cache is also available for requests that are routed to different containers. A battle-tested solution for this is Memcached, which is available via the [MemCachier Add-on]. Refer to the [managing Add-ons](#managing-add-ons) section on how to add it. In addition the [MemCachier Documentation] has detailed instructions on how to use it for your language and framework of choice.