CARVIEW |
Select Language
HTTP/2 200
date: Fri, 10 Oct 2025 20:54:08 GMT
content-type: text/html
content-encoding: gzip
content-location: 0160.html
vary: negotiate,Accept-Encoding
tcn: choice
last-modified: Thu, 13 Jul 2023 17:54:16 GMT
cache-control: max-age=2592000, public
expires: Sun, 09 Nov 2025 20:54:08 GMT
access-control-allow-origin: *
x-request-id: 97ec7132bd6f74ac
strict-transport-security: max-age=15552015; preload
x-frame-options: deny
x-xss-protection: 1; mode=block
cf-cache-status: REVALIDATED
set-cookie: __cf_bm=iXzqN.3qoR3fxhc6oHBWxpjfQ3XEFAxTuDPTLsId6jA-1760129648-1.0.1.1-.MRGq.HS2a6RgIfSueVCZUlnap6hUdkSSq2XdfzUbMAES6PNmxDGdEs2Fg6Xin4ttwCIUxGD6SSb3e4HBzN.a6kIgKeaZON8btUhymvHeaU; path=/; expires=Fri, 10-Oct-25 21:24:08 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None
server: cloudflare
cf-ray: 98c902dedc7ec1bd-BLR
alt-svc: h3=":443"; ma=86400
[Fwd: Re: Updated finding: "URIs, Addressability, and the use of HTTP GET and POST"] from Ian B. Jacobs on 2003-09-24 (www-tag@w3.org from September 2003)
[Fwd: Re: Updated finding: "URIs, Addressability, and the use of HTTP GET and POST"]
- 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) https://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