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

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

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 01 Oct 1996 18:50:20 -0500 (EST)
To: masinter@parc.xerox.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01IA506E7CNM0092EU@SCI.WFBR.EDU>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1676
Larry Masinter <masinter@parc.xerox.com> wrote:
>In an offline discussion with Foteos Macrides, we explored the various
>pros and cons of REPOST vs. Idempotent: yes. I'm not sure we've
>reached closure yet, but there was a side topic that I thought I'd
>bring up:
>One of the concerns about bookmarking 'POST' requests, whether
>idempotent or not, whether the client warns or not, is that some POST
>requests contain passwords or other 'hidden' information.
>Even if a POST result were identified as idempotent, clients might not
>want to quietly save all of the input data on a hotlist in such
>Maybe there's more about a POST result than just 'idempotent' that's
>actually useful, as in 'is it safe to bookmark the request'
>independent of 'is it safe to redo the POST'.

	Just to elaborate on that, as already stated in the HTTP/1.1 draft,
only the server (actually, in the case of FORMs with METHOD=POST, its CGI
script) can determine if a POST is idempotent, based on how the content
entity in the request is handled by the server/script.  Therefore, it is
important (IMHO) that the HTTP protocol provide for an Idempotent reply
header by which the client can be informed if the POST was idempotent
("yes"), with the default remaining "no".

	The issue of possibly sensitive material in the POST content
perhaps should me mentioned in comments of the HTTP/1.1 draft, but
the client will already have the information it needs to make judgments
about that and inform or warn the user in conjunction with a bookmarking
request, so I don't see any need for modications or additions to the
the HTTP protocol, per se, with respect to that issue.  I'll put it
even more strongly:  The client should *not* defer judgment on that
issue to the server/script.


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
Received on Tuesday, 1 October 1996 15:57:27 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC