Re: State, when to use GET, and accountability

I think the point is that doing a GET is not supposed to incur any 
obligations.   Rfc 2616 says:

"the convention has been established that the GET and HEAD methods SHOULD 
NOT have the significance of taking an action other than retrieval. These 
methods ought to be considered "safe" ...  Naturally, it is not possible 
to ensure that the server does not generate side-effects as a result of 
performing a GET request; in fact, some dynamic resources consider that a 
feature. The important distinction here is that the user did not request 
the side-effects, so therefore cannot be held accountable for them."

So, proxies are one example, which I've given, so are mechanisms that 
pre-cache access.  If some user agent running on my system chooses to 
dereference a URI, that might leave an audit trail suggesting that "I" 
have accessed the information.  Whether that's what you want will depend 
on the circumstance, but I claim there are circumstances where that's not 
what you want, and that you shouldn't use GET in such cases.   I do agree 
that leaving a mark in an audit trail is a less clear cut issue than, say, 
cancelling a subscription when someone clicks on a link.  Some audit 
trails are used primarily for things like debugging, and clearly it's 
reasonable for that side effect of the GET to occur.  Given legislation 
like Sarbanes-Oxley in the United States, an entry in an audit trail can 
conceivably have legal implications at least as great as cancelling a 
magazine subscription.  In such cases, I think GET is inappropriate, and 
I'm not convinced that must-revalidate headers in general solve all the 
problems.

Noah

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.3

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Jon Hanna <jon@hackcraft.net>
Sent by: www-tag-request@w3.org
03/06/2007 07:14 AM
 
        To:     www-tag@w3.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        Re: State, when to use GET, and accountability



noah_mendelsohn@us.ibm.com wrote:
> I'm not concerned so much with cases in which a cache is being used on 
> behalf of a single user of HTTP;  my real concern was about shared proxy 

> caches, which are quite common.  With those, you might request some 
> information using HTTP GET, and your access would be appropriately 
> recorded at the origin server.   My concern is with the case in which I 
> come along to request the same information, but a proxy cache somewhere 
in 
> the network satisfies the request without contacting the origin server. 
My 
> access is likely not recorded, except in the unusual special case that 
the 
> proxy and the origin server are cooperating on maintaining the audit 
> trail.

Is this really an issue.

Sure someone could fail to send must-revalidate headers, but they could 
also forget to make sure they logging application has write permissions 
where it should be logging and the logs aren't all silently failing.

Bugs happen, but the specs cover this concern already.

Received on Friday, 9 March 2007 19:17:33 UTC