Caching data returned from POST, and conditional POST

I noticed that Netscape (2.0b4) sends a conditional POST when data
cached that was returned from a POST expires.

However, draft-ietf-v10-spec-04 p.27 says "Applications must not cache responses
to a POST request", and draft-ietf-v11-spec-00 p35. says "Responses to this
method are not cachable".

I think this is a case where both drafts are clearly incorrect.

The logic for this is that the GET and POST methods are logically
indistinguishable. Both send a request with arguments and result in
the return of data. An end user sees no difference between them and expects
the "Back" and "Forward" buttons to act in the normal manner in retrieving
cached data. That is, a browser MUST cache the results of a POST if it is
to behave correctly.

The server has ample control over caching at the browser or by proxies
and can use this to ensure that such caching is not problematic to a
transaction sequence that changes the state of data at the server.

There are many POST-based transaction sequences that remain stateless
at the server by using hidden fields to pass state information back to the
client. These sequences rely on browser caching to allow the "Back" command
to be used as an "Undo".

I propose that the statements about caching be removed from both specifications.

I propose that conditional POST have the same status as conditional GET.
It is harmless to existing practice since servers can continue to take no
notice of the "If-Modified-Since" field for a POST if they wish.

b.

Dr Brian R Gaines               Knowledge Science Institute
                                University of Calgary
gaines@cpsc.ucalgary.ca         Calgary, Alberta, Canada T2N 1N4
403-220-5901  Fax:403-284-4707  http://ksi.cpsc.ucalgary.ca/KSI

Received on Sunday, 31 December 1995 11:05:33 UTC