Proxy Cache Configuration

From Sense/Net Wiki
Jump to: navigation, search
  •  
  •  
  •  
  •  
  • 100%
  • 6.0.5
  • Enterprise
  • Community
  • Planned

Overview

Proxy Cache
In order to be able to setup a portal behind proxy server(s) Sense/Net provides some configuration settings to fine-adjust behavior of response for content requests.

Details

Using proxies with Sense/Net

Sense/Net supports proxy configuration by indicating cached and unmodified content in response headers. This way if a browser requests ie. an image, a proxy is allowed to serve the request and it will not get to the web server. Also, the portal is able to handle the if-modified-since requests in a fast manner, so a proxy can check if a content has been modified since it's stored last modification date, and this check will be handled by the portal with the least possible resource consumption. The portal also supports a special Purge operation, by using which the portal will instruct the proxy server(s) to wipe out a certain item from its cache immediately, so the next request will imminently be passed through by the proxy and served by the portal.

Public content caching

The proxy support in Sense/Net is basically designed to handle cacheing of public content. Don't use it to cache content that is only visible by Administrators, or logged in users, as it usually cannot be set up with proxies easily - or at all, and thus unauthorized visitors may view content that was not intended for public visibility. For permission considerations the If-Modified-Since headers are only handled for requests to nodes which are visible to the Visitor user - see details below.

Cache control headers

The following is an example for sent cache control headers in the request for a content that is configured for caching on client side and a proxy is also configured:

Cache-Control:public, max-age=600
  • public: by default this is sent for cacheable content - if not further configurable;
  • max-age=: this value contains the configured max-age setting that will instruct the client (browser) to retain the corresponding content in its cache for the specified interval. Given in seconds.

The above header values are configurable for different content / applications, see details below.

If-Modified-Since

For cacheable content clients may send a special header with requests to check if a content has changed with respect to what is stored in their client cache. Usually, browsers do this if they received a Last-Modified HTTP header, and upon subsequent requests, they send an If-Modified-Since header.

Proxies should forward these requests towards the portal, and it will serve the requested content in a fast manner. The supplied date is compared to the last modification date of the requested content, and in case it has been modified since, the fresh content is served, otherwise the client is instructed to use the item stored in its cache by sending a HTTP 304 Not Modified response.

Sense/Net serves a Last-Modified header always when appropriate.

Because of security considerations, requests containing an If-Modified-Since header are only handled with HTTP 304 Not Modified if the request addresses a node to which the Visitor user has See/Open permissions.

Note: Bundles are special and will always serve Last-Modified headers and they will always respond to request with the If-Modified-Since header.

Note: Versions prior to Sense/Net 6.1.1 served these requests only when the portal was behind a proxy.

Whether the request comes from a proxy is determined by a Web.config setting for the sender's IP address - see Cache configuration below.

Cache configuration

1. Images and static files
To send cache control headers and handle if-modified-since requests for a predefined set of content, define the rules in the Portal setting content.

Prior to version 6.3 the MaxAge could be configured only by the extension of the requested content in the Web.config file. The entries define max-age values for given extensions; public is always used as cache-control.

<add key="ClientCacheHeaders" value=".jpg=600;.jpeg=600;.gif=600;.css=600;.png=600;.js=600;.swf=600"/>
2. Binaryhandler
To send cache control headers and handle if-modified-since requests for requests handled by /binaryhandler.ashx (used by Image Field), set the appropriate value in the Portal setting content.

Prior to version 6.3 you could use the following Web.config setting to define MaxAge for requests sent to /binaryhandler.ashx (the entry define max-age value for all binaries, public is always used as cache-control).

<add key="BinaryHandlerClientCacheMaxAge" value="600"/>
3. Applications
To send cache control headers and handle if-modified-since requests for content served by a given application, set the following properties of the Application:
4. Proxy settings
To define proxy ips for the portal, use the following web.config setting:
<add key="ProxyIP" value="ipv6_1,ipv6_2,ipv6_3" />
This header contain the source ip in ipv6 format, so it is desirable to provide the ip addresses of proxy servers in ipv6 format. For testing with localhost you can use ::1.

Example/Tutorials

1. Setting up Varnish proxy to disallow browser cache

When using a proxy that can handle purge requests (see Proxy Purge API) it is undesired to allow the browser to cache items for the given max-age. If a URL is purged from proxy, it is not the proxy that will handle the next request to the given url from its cache, but the portal will serve it from the Content Repository, which makes it possible to show changes immediately even when using a proxy. In this scenario it is undesired that the browser also caches the content, as it will not send requests to the proxy for the given max-age and changes will not be seen. The headers sent by the proxy to the client has to be modified to avoid this. The following code is an excerpt from a Varnish log, that will send private cache-control headers to the browser, and will leave headers intact only in the case of images:

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
        set resp.http.X-Cache-Hits = obj.hits;
    } else {
        set resp.http.X-Cache = "MISS";
    }
 
    #send MaxAge to the client only if it is an image
    if(!(req.url ~ ".*\.(jpg|png|gif|css|jgp|js|axd|ico).*$")) {
        set resp.http.Cache-Control = "private, max-age=60";
        remove resp.http.Last-Modified;
    #if image, js or ico
    } else {
        set resp.http.Cache-Control = "private, max-age=86400";
 
    }
 
   return (deliver);
}
2. Setting up Varnish proxy to serve requests even if backends are down

We can use proxies to keep our sites responsive even if the backend servers are down for some reason. Configuring grace periods tells Varnish to keep objects in cache past their expiry time and deliver otherwise expired object when the backends are not healthy. You can activate this feature by setting grace periods in vcl_recv and vcl_fetch and configuring Health Polling for all backends.

Set the grace period

In the following example we set the grace period to one hour if the backend is not healthy which means the proxy can serve expired cached objects for one hour if the backends are down.

sub vcl_recv {
  if (!req.backend.healthy) {
    set req.grace = 1h;
  }
}
 
sub vcl_fetch {
   set beresp.grace = 1h;
}

Enable backend polling

In the following example we configure health polling for example.com by adding the probe member to the backend definition. With this settings varnish will poll example.com/test.html in every 5 seconds and the value of req.backend.healthy will depend on the status code of the response.

backend backend1{
    .host = "example.com";
    .port = "80";
    .first_byte_timeout = 300s;
    .probe = {
        .url = "/test.html";
        .timeout = 10s;
        .interval = 5s;
        .window = 1;
        .threshold = 1;
    }
}

You can read more about this topic on the wiki page of the feature.

3. Setting up multiple backends for Varnish proxy

Varnish supports load balancing.

To configure multiple backends and load balancing you have to go through the following steps:

Requests with www.example.com host header will be forwarded to exampleDir director.

sub vcl_recv {
    if (req.http.host == "www.example.com") {
        set req.backend = exampleDir;
    }
}

The director will send the request to one of the following backends in round robin fashion.

director exampleDir round-robin {
{
    .backend = backend1;
}
{
    .backend = backend2;
}

We have to define the backends with the same names used in exampleDir section.

backend backend1 {
    .host = "backend1.example.com";
    .port = "80";
    .first_byte_timeout = 300s;
    .probe = {
        .url = "/test.html";
        .timeout = 10s;
        .interval = 5s;
        .window = 1;
        .threshold = 1;
    }
}
 
 
backend backend2 {
    .host = "backend2.example.com";
    .port = "80";
    .first_byte_timeout = 300s;
    .probe = {
        .url = "/test.html";
        .timeout = 10s;
        .interval = 5s;
        .window = 1;
        .threshold = 1;
    }
}

You can read more about this topic on the wiki page of the feature.

Related links

References