Re: Caching data returned from POST, and conditional POST

Shel Kaphan writes
> 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.
>

I think it is clear what it means. The server should be able to identify
the data it sent back from a POST has changed in the same way as it does
that from a GET. It is up to the server to keep track of its state
changes in doing this.

As a general comment on your responses, I think it inappropriate for
the HTTP protocol itself to attempt to take account of server state.
It should provide the means for the server to control the browser so
that it can manage user interaction properly, but should not attempt
to enforce arbitrary models of what is a general client-server system.

There are many different ways of handling state and contention in
client-server systems and the appropriate mechanism varies widely
according to the application. The HTTP specification should allow
the system designer to design the most effective system. It should give
control over caching, not say it should not occur when it clearly
should and clearly does.

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

What you describe would be very bad practice. I want the browser to
check with the server when the user uses "Back" and "Forward" so that
the server can ensure that the data is up to date. Netscape does precisely
this and enables the user interface to be kept in sync with the state
of the server.

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

We have major interactive applications that use hidden fields to carry
state data effectively. I detailed the advantages of this in the
"Porting" tutorial at WWW4 <http://ksi.cpsc.ucalgary.ca/articles/WWW/PortWeb>.

The major browsers all deal correctly with hidden fields and minor ones
that do not will presumably be debugged to do so.

Storing state in hidden fields make it possible for "Back" to act as "Undo"
which is what users expect. When the "Undo" is impossible or ambiguous
the server can query the user in the normal way for a transaction-processing
system.

I guess the generic point is to avoid building specific TP architectures
into HTTP. It is a general transport and control protocol capable of supporting
many TP architectures.

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 12:18:38 UTC