Re: using opaque strings to determine uniqueness

On Tue, 14 Nov 1995, Jeffrey Mogul wrote:
> If you recall, I suggested that an object without an explicit Expires:
> header attached must always be validated by a proxy.  There are three
> cases:
> 	Expires: missing
> 		validation required on every fetch from any cache
> 	Expires: "never"
> 		validation never required (immutable documents)
> 	Expires: <some timestamp>
> 		validation not required until <timestamp>, but
> 		always required after that.

Okay, this would seem to solve the problem conditions I can think of.

>     That said, I think what we need for doing conditional requests is a 
>     general grammar to which we can apply file attributes.  Something like
[my proposal for Send-If, which I was informed was proposed at one point 
for HTTP as "Unless:", and will hopefully be in 1.1 - cool]

> But this implies that the clients and servers share a deep understanding
> of the attributes of the objects.  What about objects that don't have
> "modification times"?  What other attributes could be both useful and
> generally supported?  I'm as much of a fan of file attributes as anyone
> (after all, I did my PhD dissertation on the topic), but I don't think
> we should be pushing HTTP in that direction.  HTTP is not a file
> access protocol.

My mistake for calling them file attributes rather than object 
attributes - while you might refrain from calling it a "file access 
protocol", I think we could certainly agree to call it an "object request 
protocol".  To some extent, "Send Unless" and conditional GETs are just 
an optimization over doing a HEAD request on an object before fetching 
it, so i'm not going to proclaim that the WWW will fall apart if it's not 
implemented.

> And if someone does come up with another use for attributes, are these
> really the right thing to use for cache validation?  I think not.

I will defer to the cache validation experts.  Of which there don't seem 
to be many :)

	Brian

--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com  brian@hyperreal.com  http://www.[hyperreal,organic].com/