"Expires" again...

Paul Burchard (burchard@horizon.math.utah.edu)
Thu, 12 Jan 1995 21:55:57 +0100

Chris Wilson <cwilson@spry.com> writes:
> Bill Allocca <allocca@OpenMarket.com> writes:
> >Is there any way in HTTP for a Server to automatically update a page
> >without requiring the user of the client to click on anything?
> Because of the other problems that you noted (namely,
> that clients are not required to automatically reload a
> document when it passes the Expired time- in fact, it
> would be detrimental to do so),
> >there are cases where a page is valid only once --
> >they expire immediately and the client shouldn't get
> >them again.

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

> 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...''