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

Re: REPOST (was: HTTP working group status & issues)

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
Message-Id: <96Sep27.144131pdt."2759"@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1662
> 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.

Received on Friday, 27 September 1996 14:47:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC