[Fwd: Re: Updated finding: "URIs, Addressability, and the use of HTTP GET and POST"]

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

Received on Wednesday, 24 September 2003 09:06:08 UTC