The presence of my suggested expires header in 302 responses would
serve to _enable_ cacheing, the draft http spec now implies that 302
responses should never be cached.
>Netscape does this already with a pragma
>directive - with dynamic documents (say an order form where you don't want
>the history to point at an old version) I use both that expires and the
>nocache directive just to be sure.
You mean to say that the Netscape _browser_ disables its internal
cacheing when receiving a pragma: no-cache in a form _response_?? That
would be strange but wonderful, as the draft http spec defines this
pragma to be an optional part of a client _request_ message.
In general, the expires header is a completely adequate mechanism for
disabling cacheing, _if only browsers would actually interpret it_.
In the last Lynx and Netscape versions I tested, the internal cache
just ignored expires, in effect there seemed to be no mechanism at all
to get anything dropped from the internal cache.
To deal with these broken caches when implementing a dynamic service,
I actually ended up generating one-time dynamic URLs for everything!
Ugh.
BTW, while the expires header is adequate for disabling cacheing, it
is not adequate for controlling history list contents, see the first
few messages in this thread. If you, as a dynamic form author, want
to make the history list never point to an old version, you are out of
luck.
As a dynamic service author, I have often wanted to have the ability
to mess with the history lists of the users. Having this abilitity, I
could improve the safety and navigation speed (no more backing up
through forms) of my service.
However,
1) I can't change history lists with current browsers
2) I can't think of any general yet safe command language for
communicating history list manipulations to the browser
3) dynamic history lists have the potential of being very confusing
4) I don't think all users will appreciate me changing their history
lists
5) I certainly would hate to have my history list `improved' by every
bozo with a bright idea whose site I happen to browse
6) a mechanism for changing history lists opens a whole new realm of
subtle security considerations.
>Kee Hinckley Utopia Inc. - Cyberspace Architects 617/721-6100
>nazgul@utopia.com http://www.utopia.com/
Koen.