W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Caching data returned from POST, and conditional POST

From: David W. Morris <dwm@shell.portal.com>
Date: Wed, 3 Jan 1996 16:52:26 -0800 (PST)
To: http working group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <Pine.SUN.3.90.960103153226.17565F-100000@jobe.shell.portal.com>


On Sun, 31 Dec 1995, Brian Gaines wrote:

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

> 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

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.

Much of the confusion is induced by web page designeers who put
anchors on their pages and label them 'BACK'. They DO NOT perform a
BACK function in general they polute the history list with anouther
perhaps different copy of a document.

To resolve this confusion we need to take some part of the WWW spec
forward to cover these additional cases such as:
  1.  REDO/UNDO as explicit browser buttons which also are reported to
      the server as requests which can be differentiated.
  2.  Provide some HTML mechanism which allows the application 
      developer to place the BROWSER button functions (BACK, FWD?, 
      REDO/UNDO, ...) within the WEB content. Then when the author
      wants to represent 'back' on the page, they have the choice
      of obtaining exactly the browser button semantics without
      stupid phrases like "Click the BROWSER BACK button and fix the
      xxx field and resubmit".

  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.


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

There is no such security today and to change the expected behavior of
existing applications in an attempt to force fit it would be wrong.

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. 

Perhaps a candidate for a future sub-group.

Dave Morris
Received on Wednesday, 3 January 1996 16:57:15 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:42 EDT