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

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.

>-P

Koen.

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