- From: Werner Baumann <werner.baumann@onlinehome.de>
- Date: Fri, 26 Oct 2007 22:05:12 +0200
- To: ietf-http-wg@w3.org
Scenario: A caching proxy that serves not one, but many clients (the most common case). Case a) 1. Client X requests resource A. 2. The proxy gets resource A from the server, stores it in the cache and delivers it to client X. 3. Some time later client Y requests resource A. The proxy checks whether the cached entity is up-to-date and serves the cached entity. Let's assume the proxy checked well and the entity is up-to-date. Case b) The same case with client Z, which likes "no-store". 1. Client X requests resource A. 2. The proxy gets resource A from the server, stores it in the cache and delivers it to client X. 3. Client Z requests resource A with "no-store". The proxy serves this request and does *not* change the cached entity A, nor any of the meta-data about resource A. 4. Some time later client Y requests resource A. What do do? Either the cached resource A is Schrödinger's Cat, or the proxy may serve the cached entity just like in case a, and the cached entity is valid. After all, the cached entity in case a and case b are exactly the same. If a client does a request with the "no-store"-directive, this request and the response are out of the scope of caching, and MUST NOT influence the cache in any way. On the other hand, if the proxy would delete the cached entity, the danger of a denial of service attack is real. This must not be by intention. Anybody may write some HTTP-Client, and may by mistake think it a good idea, to use the "no-store"-directive. Werner
Received on Friday, 26 October 2007 20:05:33 UTC