If-Modified-Since HTTP support in NSI for external caches of structure & data query responses to reduce NSI/SQL work load
Technical notes
HTTP validation is used by servers and caches to communicate when a representation has changed. By using it, caches avoid having to download the entire representation when they already have a copy locally, but they’re not sure if it’s still fresh.
The most common validator is the time that the document last changed, as communicated in Last-Modified
header. When a cache has a representation stored that includes a Last-Modified
header, it can use it to ask the server if the representation has changed since the last time it was seen, with an If-Modified-Since
request.
The NSI should know when structures or DSD's data have been updated last, and it should be possible to provide the Last-Modified
header in all responses to normal requests using this information.
We would also need to implement a validator in the NSI to respond to If-Modified-Since
requests. This can be done by parsing the HTTP headers, and responding with 304 Not Modified
when appropriate (instead of resending the content).
An alternative for (or additional feature to) the Last-Modified
header is the ETag
header, which contains a content-version-specific tag instead of the version datetime. If the version tag has changed is to be tested in the NSI validator used for requests having the If-None-Match
header. The ETag
feature takes precedence over Last-Modified
. However, Last-Modified
seems to be more user-friendly (since it can be interpreted by clients) and the version datetime should exist already in the database. Thus only the Last-Modified
header should be implemented.
Note: If the request is authenticated or secure (i.e., HTTPS), it won’t be cached by shared caches, but only by private caches (e.g. user's web browser cache).
The NSI already supports this header, but the lastupdated information seems wrong in .Stat CORE thus the feature currently doesn't work as expected.