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

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

From: Patrick McManus <mcmanus@appliedtheory.com>
Date: Thu, 20 Mar 1997 15:44:14 -0500 (EST)
Message-Id: <199703202044.PAA09916@pat.appliedtheory.com>
To: "David W. Morris" <dwm@xpasc.com>
Cc: mcmanus@appliedtheory.com, http-wg@cuckoo.hpl.hp.com

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.

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)..

The fact that control over r/w should remain with the client at that
granularity is analagous to our daily commerce lives... when you are
in a store and purchase something with your credit card, you can't be
absolutely sure that they will bill you what you have agreed on.. but
you let them make the transaction anyhow. however if you aren't ready
to buy anything I don't know anyone who gives their card up at the
door just so they can bill you $0.00.. Why extend un-necessary
authority?

-P
Received on Thursday, 20 March 1997 12:44:16 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:32 EDT