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

koen@win.tue.nl (Koen Holtman) wrote:
>>Foteos Macrides:
>>[...]
>>I'd personally feel more comfortable about something
>>like  Accountable: yes : no  with default "yes" for POST.
>
>So you want the implied semantics of `safe: yes' rather than
>`redo-safe:  yes'?  I could live with that.

	"Safe" is short, and precisely defined in Section 9.1.1, so
an optional  Safe: yes | no   with default "no" for POST seems, all
things considered, optimal.


>>        I can image CGI author's putting a line for sending a
>>Redo-Safe: yes  header without code to check for whether the COD
>>hardcopy request has been checked, than an  Accountable: no  header.
>
>I don't know if I agree; predicting the mistakes of CGI authors is a
>tricky business.  Anyway, I'd like to delay the discussion about the
>best name for the response header until the `link rel=source'
>vs. `redo-safe' issue is resolved.  We need to agree on semantics
>first.

	RFC 1866 provides for HREF, REL, REV, URN, and METHODS
attributes in Anchor start tags, and collectively they almost provide
everything that would be needed for bookmarking of POST requests for
resubmission via Anchors in HTML files.  What's missing is a clean way
to specify the ENCTYPE <-> Post-Content-Type when it's not the default
(application/www-form-urlencoded).  The object still would have to
be structured as a parameters <-> headers section followed by the
actual Post-Content.  You want that structure anyway, if you don't
set up parameter conventions for URLs, and the latter is beyond the
scope of this WG.  Technically that's also true for REL and REV
naming conventions.

	The real issue is that only the server/CGI-script can determine
whether the Post-Content which accompanied a POST request is safe.  If it
is, the server/script can simply return a  Safe: yes  header for the UA
to use as the UA sees fit, if anything, or the server can itself create
an object which includes that Post-Content for future reuse.  Such an
object may be safe with respect to side effects for which the UA is
accountable, but may contain sensitive or personal information, may have
been transmitted with encryption, etc.   Thus, instead of just absolving
the UA of accountability for any side effects of the POST with that
content via a reply header, the server/provider may also be taking on
responsibilities related to security and privacy.

	The  Safe: yes | no  header is a simple thing that would involve
adding just a few lines of text to the -07 draft, and doesn't even merit a
separate ID (I'm sure Koen could try it as a midnight hack, and it would
read fine in the morning 8-).  The rel=source approach is complex, and
would require considerably more discussion and further modifications of
the -07 draft than perhaps is appropriate at the tail end of it becoming
an RFC.

	The two approaches are not mutually exclusive, and the
rel=source approach is the one that would require a substantive ID,
if anyone really wants to pursue it.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================

Received on Sunday, 6 October 1996 10:15:00 UTC