W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1995

Re: Logic Bag concerns

From: John Franks <john@math.nwu.edu>
Date: Thu, 30 Nov 1995 21:00:38 -0600 (CST)
Message-Id: <199512010300.VAA11669@hopf.math.nwu.edu>
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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:42:57 UTC