Cache Behaviour
There are several ways that BVR determines whether or not to cache a resource and how
long it is considered usable in the cache.
In BVR cache directives are either associated with the resource itself or apply only
to an individual request to that resource.
The expiry times displayed by the bam --cache command and stored in the cache's metadata are the expiry times associated with the resource itself.
Cache directives supplied on a per-request basis (for example: using the maxage attribute in a goto or audiomaxage in the audio tag) are not stored or displayed
for the cached item but are just used to determine whether the cached version of the resource should be used for the current request.
Cache control directives on a resource are hierarchical, the order of preference is as follows:
- HTTP header values returned by the HTTP server: When a resource is fetched from an HTTP server, it may supply cache directives on the HTTP response in the HTTP Cache-Control
header. These are resource associated cache directives.
- Directives defined in the "http-equiv" meta tag: These override cache directives returned by the HTTP server. These are resource associated cache directives.
- Individual request directives (for example: maxage/maxstale attributes on fetch/dialogstart etc.). These are only associated with the current request and are
not stored against the resource's metadata in the cache. These directives take precedence over all others.
If no cache control directives are specified for a resource the resource_max_age configuration setting for CCXML (CCXML Cache Configuration Options)
will be used as the expiry time and will be stored against the cached entry.
Note that since RFC2616 states that HTTP max-age directives take precedence
over the HTTP Expires header, so too does the resource_max_age configuration setting.
Example of Behaviour
Consider the following CCXML snippet (Note: Assume that the VoiceXML documents do not have
their own meta http-equiv cache control directives):
<meta http-equiv="cache-control" content="max-age=60"/>
<!--......(application logic)......-->
<dialogstart src="'1.vxml'" type="'application/xml+vxml'" connectionid="evt.connectionid" maxage="'60s'"/> <!--HTTP server returns with Cache-Control: max-age=10 for this resource-->
<!--......(application logic)......-->
<dialogstart src="'2.vxml'" type="'application/xml+vxml'" connectionid="evt.connectionid"/> <!--HTTP server returns with Cache-Control: max-age=10 for this resource-->
<!--......(application logic)......-->
<dialogstart src="'3.vxml'" type="'application/xml+vxml'" connectionid="evt.connectionid"/> <!--HTTP server returns no Cache-Control directives for this resource-->
If the configured
resource_max_age for CCXML and VoiceXML is set to 3 minutes, the first call into the application would have the following results:
- Fetch the CCXML document with a max age of 60 (as this is set in the http-equiv meta tag) and put it in the cache
- Fetch 1.vxml and cache it with a max age of 10 seconds
- Fetch 2.vxml and cache it with a max age of 10 seconds
- Fetch 3.vxml and cache it with a max age of 3 minutes (using the default resource_max_age configuration setting for VoiceXML)
Then, on another call 20 seconds later:
- Use the CCXML document from the cache as the max age was 60 seconds and this call was made 20 seconds after the one that put the document in the cache
- Use 1.vxml from the cache as, while the HTTP server specified max-age of 10 seconds (which is associated with this resource), the dialogstart tag says that
it will accept a resource that is as old as 120 seconds
- Fetch 2.vxml. The HTTP server specified a max-age of 10 seconds and this has not been overridden
- Use 3.vxml from the cache as the HTTP server did not specify any cache rules and they were not overridden, so the default resource_max_age configuration setting is used.