WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

When using NKP, resource representations may be cached at both the server and client side of a connection if the expiry metadata associated with a response permits and each cache is managed independently.

Expiry metadata is transmitted transparently with a response over NKP. Expiries of ALWAYS, NEVER and CONSTANT can be sent without need for a remoted expiry function but all other expiration methods require one. A remoted expiry function involves making a call back to the server to check if a representation's validity has expired. In NKP2 expiry functions are requested asynchronously - this means your application will never block due to network latencies.

Because it may be expensive to constantly poll a server for expiry status of every response it has served, especially for geographically remote servers a compromise must be made. Servers may specify a minimum poll period in which to check remote expiries. This limits checks to a maximum of once every so many milliseconds. Servers can specify a global configuration value. In addition endpoints on the server may specify a custom NKP_REMOTE_EXPIRY_POLL header with a java.lang.Long value to specify a custom poll period. A poll period of zero will force a check on every access will ensure a stale value is never assumed valid.