- From: John Franks <john@math.nwu.edu>
- Date: Thu, 30 Nov 1995 21:00:38 -0600 (CST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: john@math.nwu.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
According to Jeffrey Mogul: > > Can you explain why we need both > If-cache-valid: <validator> > and > If-cache-stale: <validator> > instead of simply > Cache-validator: <validator> > along with a set of rules that explain how it is supposed to > be interpreted? > > E.g., for > GET > Range: 3-8 > Cache-validator: XYZZY > I would expect the semantics to be > if the validator of the actual object is XYZZY then > return range 3-8, else return the whole thing > I could live with this. But I worrly a little about the clarity. Compare GET /foo Range: bytes=30-80 Cache-validator: XYZZY and GET /foo Cache-validator: XYZZY In the first case the server honors the the (range) request only if the validator is XYZZY; in the second it honors the request only if the validator is NOT XYZZY. I would prefer a little more redundancy for clarity. E.g. GET /foo Range: bytes=30-80 If-Cache-Valid: XYZZY and GET /foo If-Cache-Stale: XYZZY You are correct that this isn't strictly necessary. But remember it is only the validator we want to be opaque, not the header :) John Franks
Received on Thursday, 30 November 1995 19:15:08 UTC