Re: Caching data returned from POST, and conditional POST
Brian Gaines (gaines@cpsc.ucalgary.ca)
Wed, 3 Jan 1996 20:33:28 -0700
I thought we were moving this discussion to the caching list and haven't
been continuing it here but David Morris' mail requires an answer.
One answer is that the document by Holtman and Kaphan at
http://www.amazon.com/expires-report.html cover all the issues that I
raised in a very much more precise and comprehensive fashion that my
mail or the responses it initiated. It is an excellent basis for
resolving the issues as part of the caching sub-group discussion.
Key points in that document are: a) the logical separation of caching for
purposes of history from caching for purposes of speed/traff-reduction;
b) the need for apparently user-interface issues to be part of caching logic;
c) the proposal for a tag applicable to the history list whereby the server
can designate the appropriate behavior for history list items.
The proposal would cover the various transaction-processing situations
that we have enumerated -- it would be useful to look for counter-examples
where it will not.
>> As I noted previously, conditional POSTs make the same sense as conditional
>> GETs so there is nothing wrong with what Nescape is doing. It does not
>
>What you noted previously is INCORRECT based on a long history of
>discussion on the HTTP and HTML lists. Just because the latest Netscape
>beta changes behaviour doesn't make it correct behaviour. There is an
>essential difference between GET and POST ... GET is not supposed to
>cause state changes in the server which would cause the response to
>a subsequent GET to be different. POST may make such changes.
>