- From: Moore, Jonathan (CIM) <Jonathan_Moore@Comcast.com>
- Date: Thu, 7 Apr 2011 09:57:41 +0000
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
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