Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Added section about cookies allowed by Varnish #222

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Added section about cookies allowed by Varnish #222

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3881e4f
Added section about cookies 'allowed' by Varnish
holtkamp May 21, 2015
fb55c81
Included examples of static and dynamic content
holtkamp May 21, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 38 additions & 5 deletions Platform Documentation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
<ifmodule mod_expires.c>
<FilesMatch "\.(html|js|css|txt|xsl)$">
ExpiresActive on
ExpiresDefault "modification plus 1 day"
Header append Cache-Control "public"
Header unset Set-Cookie
</FilesMatch>
</ifmodule>

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

Expand Down