RE: SHOULD-level requirements in p6-caching

Poul-Henning Kamp writes:
>In message <90400372-C89F-4E9C-92F6-D8F1A6AAD631@mnot.net>, Mark Nottingham writes:
>>In 3.2.1 (only-if-cached),
>>
>>>       If it receives this
>>>       directive, a cache SHOULD either respond using a stored response
>>>       that is consistent with the other constraints of the request, or
>>>       respond with a 504 (Gateway Timeout) status code.
>>
>>MUST?
>
>I must confess I have never understood this directive, nor been able to
>come up with a non-hostile intent for using it.  Can anybody enlighten me ?

This is primarily useful in the presence of client-side caches attached to applications. Let's say I have an in-memory object that is a parsed representation of some resource http://foo.example.com/obj. In the course of serving a synchronous client request, I'd like to refresh/validate my parsed representation, but not if it involves making a long WAN request to validate back to the origin. In this case, I might want to issue a conditional GET with only-if-cached; this way, I get a fast response with either (a) 504, (b) 200 with updated info loaded from client cache, (c) 304 validation from client cache. If I get a 504, I might then follow up with an asynchronous validation request without only-if-cached, but maybe not.

This is important because my parsed object with its validator is a very tiny client-side cache, and while I want to revalidate it, it's possible that the previous cache entry has disappeared from my local client HTTP cache.

In short, it allows a client with a client cache to control the latency of the request/response cycle, including doing client-driven stale-while-revalidate.

Jon

Received on Thursday, 7 April 2011 09:58:17 UTC