W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: draft-holtman-http-safe-01.txt

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 21 Mar 1997 09:33:03 +0100 (MET)
Message-Id: <199703210833.JAA22893@wsooti08.win.tue.nl>
To: mcmanus@appliedtheory.com
Cc: dwm@xpasc.com, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2804
Patrick McManus:
>I'm just going to try and summarize my issue with koen's safe draft
>(and dave's subsequent uhint draft as it applies to safe requests). 
>In the past permission over whether or not side effects were allowed
>was always a client side decision, initiated via choice of
>method. This served as a sort of 'write protect' mechanism. The fact
>that some applications may have ignored this isn't germane, they're
>non compliant in my opinion.

I agree.

>All I want is a procedure where clients can continue to ask for r/o
>status but do so with requests bearing message bodies. The fact that
>they wish to do so should not have as a requirement previous communication
>with the hopefully safe resource.
>it's been suggested that adding safe: as a request header to post
>accomplishes this, but that in no way assures that a completely
>compliant 1.0 app honors the safe:'d POST request.. (whereas a compliant
>1.0 app would refuse to do unsafe writes via a GET)..

Yes, adding safe: as a _request_ header does not get you the reliable safety
you need: we need a GET-WITH-BODY for this, but we cannot deploy it soon
because all old clients out there won't understand it.

The Safe response header solves _some_ of the problems we have because we
don't have GET-WITH-BODY.  Once we GET-WITH-BODY is deployed though, Safe
becomes superfluous.

So it is Safe now, GET-WITH-BODY later.


Received on Friday, 21 March 1997 00:35:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC