The current HTTP draft spec *does* specifically
interpret "Expires:" as a client directive to
automatically reload the data at that time -- i.e. expiry
interpreted as "data expiry".
However, along with Dan Connolly, and others that Bill
Allocca mentions, I also originally interpreted
Expires as a server guarantee to deliver constant data up
to that time -- i.e. expiry interpreted as "URL expiry".
My own example of "URL expiry" without "data expiry" was
that of custom inline images inside FORM-generated
documents, which get deleted from the server
immediately upon retrieval. According to the HTTP draft
spec, I should not tell the client to "expire" these
images.
> I would propose an "Expires-Auto-Update:" field - with a
> value of "yes" or "no", default "no" in case of the header
> line not appearing - which would force the client to
> automatically update the page.
Since, "data expiry" and "URL expiry" are independent
issues, as the examples have shown, it seems like we
really need two independent time headers, say
"Data-Expires:" and "URI-Expires:".
According to the current HTTP spec draft, "Expires:" means
"Data-Expires:", and this does seem like the more generally
useful one.
--------------------------------------------------------------------
Paul Burchard <burchard@math.utah.edu>
``I'm still learning how to count backwards from infinity...''
--------------------------------------------------------------------