Caching data returned from POST, and conditional POST

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

What does that mean?  A POST with if-modified-since?  I don't believe
this is has been defined, and it doesn't really make sense unless the
if-modified-since only applies to the returned data, not to the action
of the POST, since POST can have side effects at the server, so doing
doing it twice is not the same as doing it once.


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

Depending on the interpretation, I either agree or not.
If "to cache" is interpreted as "to store into a cache", then I agree
that the existing specs are incorrect.  If "to cache" means "to
return a document from the cache", then I believe the spec is OK.


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

But there is a convention that GET isn't supposed to have side
effects, but POST can.  Without that convention, no caching (in the
sense of "returning documents from a cache" is possible, since there
would be no way to tell by looking at a GET request whether it will
have side effects or not.  Because of the presumption of no side
effects, GET and HEAD can be served from a cache, while POSTs cannot.
However, in my opinion the returned results from GET and POST can both be
stored in a cache, under control of the appropriate headers, and I
have strong reasons to believe that is current practice in most browsers.
I think this last issue may require some discussion in the caching subgroup.

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

No, you're confusing history functions of the browser with caching.
BACK and FORWARD can show you documents that are stored by your
browser, but are not necessarily the same set of documents as are in
your cache.  For instance, your history list may contain several
versions of the same document, e.g. a stock quote report you've asked
for every 15 minutes for the past several hours.  In addition,
although these documents are in your history list, some or all of them
may be "stale" (marked as "expired"), but BACK will show you them
anyway -- or should!  The cache comes into play when you make a fresh
request, by entering a URL, clicking on a hyperlink, or submitting a
form.  In this case the cache decides if it can simply present the
document it already has at hand, or if it must fetch a new copy.  POST
requests always have to go through to the origin server, because of
the possibility of server side effects.  Of the existing methods in
HTTP, only GET and HEAD can be served from a cache without the
necessity of contacting the origin server.  OTOH, the headers in the
resource returned by GET or POST are sufficient to control whether
that returned resource can be "cached" -- stored into a cache so that
later GETs can get that document from the cache.  (Again, this last
statement is apparently not fully agreed upon).


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

Don't get me started on hidden fields.  They're about the worst way to
handle state.  First off, not all browsers hide them, and some of
those that don't make them editable, guaranteeing that some loser will
edit them.  Secondly, precisely because using BACK loses this state,
it tends to be confusing to users.  If hidden fields must be used at
all for state handling, they should only be used extremely locally -- from one
page to the next.


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

The caching subgroup should discuss this.  I hadn't noticed these
statements in the spec before.  Thanks for pointing them out.

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

Shel Kaphan
sjk@amazon.com

Received on Sunday, 31 December 1995 11:46:07 UTC