W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

RE: SHOULD-level requirements in p6-caching

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>
Message-ID: <9BD03E7AA1D81543AE3AD67CB6FADFEC168496@PACDCEXMB03.cable.comcast.com>
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.
>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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:51 UTC