Re: Caching data returned from POST, and conditional POST

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

From some tests, what Netscape appears to be doing is just returning the
last-modified info in the if-modified field. This seems eminently sensible.
There seems no need to make a big deal out of 'conditional' from this
perspective. If the server gets its own info back it can decide what it
wants to do with it. The spec need not even mention 'conditional' just
that this info when sent shoudl be returned.

It would be nice to extend that concept and have a tag field that just
got returned. This would avoid having to tuck state info into hidden fields
under some conditions (where the user was not expected to store the state
info by saving the doc).

>I would surely like to see a serious research report which describes
>your methodology. My experience is that users use the BACK button on
>the browser to review the previously viewed material.  To change the
>material viewed when the BACK button is pressed simply because the
>server state had changed is WRONG ... imagine a book with invisable ink
>which somehow has a page you just read change because you read the
>next page and flipped back.  Back is not understood as UNDO from a
>transactional sense, it is UNDO of a page flip.  Just as FORWARD is
>not REDO but rather flip the page forward.

You can see a paper on this at http://ksi.cpsc.ucalgary.ca/WWW/PortWeb
an application at http://tiger.cpsc.ucalgary.ca/Webgrid and a paper
on the application at http://ksi.cpsc.ucalgary.ca/WWW/CSCL95WG

I've been writing about the human factors of 'undo' for some 20 years
now. It has always been a mess. Only power users use it effectively.
Normal users try and use single-level undo to late, and are confused
by multi-level systems. What we have found on the web is that users
step back to regain a previous situation and then proceed from it.
Our methodology is always to observe actual user behavior and then
make the system conform to it. The naturalness of 'back' as 'undo'
on the web is very interesting indeed.

However, note that we are not continually undoing/redoing as users
step through the history list. It is the user action of initiating
a transaction from a past state that initiates the undo. So the user
is still using the history list to observe past states as you suggest.
It is a natural extension of that to allow them to recreate the
past state if they wish.

The key trick in user interface design is to minimize the number of
controls a user has to comprehend -- back and forward also supporting
undo is a major feature. I would not see a separate redo/undo as
a plus but rather as over-engineering the interface. The nice
thing about the web is that "back" in the history list has all
the contextual info that a user needs to understand an undo action --
it is an eminently natural way of presenting an undo capability.

If the server cannot support the undo it can just return a message
saying that, and perhaps return helpful info on alternative ways
of rolling back the transaction -- since the server can know both
the present and past states it can do a very good job of this if
appropriate.

>  3.  Add via headers, response codes, methods, the ability for a
>      application to control the history list. As new functionality
>      I fully support the capabilities Brian and others have suggested
>      to allow building better applications using generic web browsers
>      by controlling the users history view. I don't believe redefining
>      existing expectations is a good idea. I also believe this is a
>      non-trivial activity.

This is well-addressed in the Holtman and Kaphan analysis.

>Part of this issue involves the grey area between caching and session
>history management which I have previously proposed as part of the
>agenda for the caching sub-group. Going beyond such clarifications
>seems like a longer term issue to define support for more transactional
>oriented applications.
>

Yes, it is a reasonable implementation technique for browsers to
use one caching mechanism for both, but they have very different
functions to the user. It is unavoidable that if one gets into history
list caching then one is into user models. This is the appropriate
differentiation: caching for speed/traffic-reduction should be
transparent to the user; caching for the history list has to support
the appropriate behavior for a particular user model. The Holtman and Kaphan
proposal addresses this.

I think this discussion does belong on the caching sub-list, have
posted it there, and suggest any follow-ups should go there.

b.

Received on Thursday, 4 January 1996 03:42:49 UTC