Has anyone managed to successfully use the
{X-Domino-CacheValidationDependsOn:] HTTP Header?
I set this header (using @SetHTTPHeader) but it seems to have no effect. The
page always fails validation even though the last modified is prior to the
specified date. Is this an absolute directive?
Subject: Cache Validation - some findings
Not even 10 years later, and here it comes, your first response, even if it is an amateur’s take.
First off, Google still lists about no resources for this custom header, except for the original IBM document describing it (IBM Developer). By making the (somewhat) educated guess, that the mentioned value should be in the same format, as for regular HTTP header fields, I used a formula like this:
@SetHTTPHeader(“X-Domino-CacheValidationDependsOn”; “Tue, 30 Apr 2013 15:04:40 GMT”)
I did not try any other date format, but using this notation, there was indeed a difference to the ETag header generated by Domino, so this is, what actually happens. Be careful with the exact formatting of the DateTime string, because at least when used e.g. in a Last-Modified or Expires header, the timezone MUST always be “GMT”, the time MUST contain seconds, month and weekday MUST be represented by their 3-letter abbreviations and day MUST have 2 digits.
If you Base64 decode the ETag header, you will see, that it consists of the user name, a couple of typical notesy looking IDs and some more rubbish, similar to this (ETag, decoded):
10-8107-C1257B5D0062F1F7-C1257B39005A37CE-5B2EABA67A9528CEC1257C080045276B-hmeliantrop
They seem to relate to database, view and document, maybe being Sequence Time IDs or so. Now, if you set the custom header to “Database”, “Document” or e.g. “Tue, 30 Apr 2013 15:04:40 GMT”, more and more parts of this string will be set to 0. Finally, if you provide a TimeDate value, the decoded ETag will look like this:
10-8107-0-0-0-hmeliantrop
However, you should take note of this paragraph from the mentioned document:
“If a TimeDate value is specified, then cache validation is accomplished by comparing this value directly with the time specified in the request’s If-Modified-Since header. This implies that when using a TimeDate value, the response must be fully evaluated before cache validation can be attempted, so cached responses are not validated using ETags.”
I have read it like twenty times and still don’t understand the hows and whys. Heck, if the ETag ist not used for validation, then why bother calculating one? But in my testing I found, that a conditional GET never returned a 304 response in this scenario, even if I explicitly set a Last-Modified header.
What I did find to be helpful in my case (just taking about views used for web navigation), was to set
@SetHTTPHeader(“X-Domino-CacheValidationDependsOn”; “Database”)
This way, Domino finally agreed to validate ALL requests to my views, including &RestrictToCategory and so on. Still I am not completely happy about it, cause I’m still struggling to fully understand the inner workings. However, it did solve my problem, despite the lack of documentation.