Re: Caching data returned from POST, and conditional POST

David W. Morris writes:

	...

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

This is indeed a gray area -- people are hesitant to try to deal with
it as part of the communication protocol, and also hesitant to deal
with it as solely within the realm of a particular content-type such as
HTML, because it doesn't really fit inside either box.  Nonetheless I
agree that much would be gained with the addition of the right set of
primitives.  Koen and I talked about this to some extent in
http://www.amazon.com/expires-report.{html,txt}, though that doesn't
address all issues.

One thing I'd like to see is tags within HTML that gave hyperlinks the
ability to pop the history stack (possibly by N pages) rather than
link to a specific document, replace the top of the stack with the
target document, go to the most recent occurrence of a document in
the stack, etc.

But I have seen nothing anywhere that defines the "history list" model
that most browsers use.  Someone could build a browser using an
entirely different model -- for instance where all pages visited are
remembered in an extended history tree, or where there's no concept of
remembering the order of visitation at all -- and not be in violation
of any standards.  Leaving it wide open does keep the door open for
innovation, and since we're still at the Model T stage with this
stuff, that's probably good.

--Shel Kaphan

Received on Wednesday, 3 January 1996 17:35:35 UTC