- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Fri, 27 Sep 1996 14:41:31 PDT
- To: mau@beatles.cselt.stet.it
- Cc: MACRIDES@sci.wfbr.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> But does it mean that the writer of the page should guess in advance whether > there could be such problems, or it is the browser which looks at the POST > method and decides to try and REPOST? The browser would only try REPOST when it was POSTing at some time other than 'pressing the submit button on this page for the first time'. This might be useful not only upon hitting "reload" when looking at the results of a page, but also if the user uses 'back' to go to a previous form and presses the submit button again (presumably without changing anything). No HTML page should have an action=REPOST in it; however, the handlers (CGI or otherwise) of POST might need to conditionally deal with REPOST as a different case if it were enabled. > Surely I am missing the point, but I find it funny to write a method with > the same syntax of an existing one - it's something like having a CONDGET > instead of the conditional GET we are used to. The choice between "adding a header to modify the semantics of an existing method" vs "adding a new method" here is dominated by backward compatibility and migration strategy. A client implementor today could just add a step where it would try REPOST and then deal with the 501 Not Implemented. Larry
Received on Friday, 27 September 1996 14:47:12 UTC