- From: Ian B. Jacobs <ij@w3.org>
- Date: 24 Sep 2003 09:06:06 -0400
- To: www-tag@w3.org
- Message-Id: <1064408766.23630.4.camel@seabright>
-----Forwarded Message----- > From: noah_mendelsohn@us.ibm.com > To: Ian B. Jacobs <ij@w3.org> > Subject: Re: Updated finding: "URIs, Addressability, and the use of HTTP GET and POST" > Date: 23 Sep 2003 17:29:25 -0400 > > Ian wrote to Noah: > >> I was afraid you would list "counters" in what > >> you consider auditing. > > >> My understanding is that the TAG did not consider > >> this type of interaction to be unsafe > Noah wrote: > I do consider it unsafe, see below. > > >> because there is no consequence for the user. The > >> fact that on the server side accesses are counted or not > >> does not engage the responsibility of the user or have > >> any consequences on the user. > > Well, I humbly suggest that if safety is related only to consequences for > the >user<, then something may be broken. Or, viewed another way, it is > the resource owner's job to decide which operations are safe, and in the > case of REST to use appropriate methods such as GET/POST to expose each > operation. So, as a resource owner, I >want< there to be a consequence > when you look up sensitive information, or when I want reliable > information about how many times someone clicked thru my link. I don't > think we want to get into the business of asking whether the user knows > there's a consequence. I could tell him or her, but who cares? The fact > is that I as a resource owner want there to be a consequence for this > access to my data. What's it to the web architecture whether I log the > names of those doing the access, their IP addresses, or just count the > number of them? What's important is whether I want a reliable count that > really represents uncached accesses from the user. If so, I would think > that POST is the right choice. > > Another way to look at it is that there is some asymmetry in the > formulation that says: "retrievals are unsafe only if the user incurs an > obligation".) The asymmetry I think I see is that POST doesn't say that > the user incurs an obligation. It says that the state of a (subsidiary) > resource may be changed. Obligation and state change seem to be apples > and oranges, except in the trivial sense that anyone requesting a state > change has some obligation to do so responsibly. Well, in the same sense, > anyone accessing a resource, accesses to which are to be tracked, is > incurring an obligation to do that somewhat responsibly too (don't bang on > the resource just to crank the counter up.) I think POST applies to both. > If the definition of GET is: "use for any access where the >user< incurs > no obligation." Then POST must be "use >only< when the >user< incurs an > obligation, even if this means you are trying to update server state using > GET", which doesn't make a lot of sense to me. -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs Tel: +1 718 260-9447
Attachments
- application/octet-stream attachment: signature.asc
Received on Wednesday, 24 September 2003 09:06:08 UTC