Re: Caching data returned from POST, and conditional POST

Shel Kaphan writes
>So far, the only conditional allowed in HTTP is GET with
>if-modified-since.  Perhaps you're referring to the fact that in
>response to BACK and FORWARD commands, Netscape allows the user to OK
>a new send of a POST when it no longer has the data (or when it has
>expired, which is against the rules in the spec, by the way).  Please
>take a look at the description of the Expires header in the spec.
>There's a short disclaimer about interactions with browser history
>functions.

What Netscape sends is:-

POST /KSS.acgi/WebGrid/Main.k HTTP/1.0
If-Modified-Since: Sunday, 31-Dec-95 17:13:19 GMT; length=3813
Referer: http://tiger.cpsc.ucalgary.ca/RealEstate/JohnMary.html
Connection: Keep-Alive
User-Agent: Mozilla/2.0b4 (Macintosh; I; PPC)
Pragma: no-cache
Host: tiger.cpsc.ucalgary.ca
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en
Content-type: application/x-www-form-urlencoded
Content-length: 3181

WebGrid=10%7C0%7C7%2F16%2F95%7C6%3A03%3A38+PM&Header=%7BIMG+SRC%3D%5C%2.........


Since this is a POST with an "If-Modified-Since:" field I am calling it
a conditional POST. If you interpret it as something else then I'd be
interested to know your reasoning.

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
conform with the specification but it is the spec that is wrong in making
inessential differences between GETs and POSTs.

>Sorry, but most users do *not* equate the BACK button with "undo", and
>in fact, most naive users don't know there's a difference between a
>link that says "go back" and using the browser's BACK button, and to
>the extent it is possible to preserve the lack of requirement for
>users to know how these things work, I think it should be preserved.
>

Your sequence of statements seem conflicting. Naive users are totally
unaware of the existence of "Undo" precisely because they just click
on "Back" and things are naturally undone. We have undertaken
usability studies of the web and users do definitely use the "Back" button
as an "undo" without any specific instructions to do so. It gives them a
great sense of security to know that they can just back out of a transaction.
As you say, they just jump back to a past state and they assume the world
is no in that state.

It is up to the system designer to program the server to manage this
situation effectively. All partial transactions are intrinsically undoable
prior to committment, and even committed transactions can usually be undone
unless the system spec makes it impossible.

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 16:35:28 UTC