Re: Logic Bag concerns

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