- From: Mark Baker <distobj@acm.org>
- Date: Thu, 19 Jan 2006 16:08:26 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: public-rdf-dawg-comments@w3.org, Kendall Clark <kendall@monkeyfist.com>
On 1/19/06, Dan Connolly <connolly@w3.org> wrote: > > And if it costs money to answer, then that requires > > your bank account be debited by that amount of money, which is a state > > change. > > Asking a question doesn't compel anybody to answer. The server > can just say "gee... hard question; I dunno" and decline to answer > (with a 403 QueryRequestRefused answer). Well sure, but that removes most of the purpose of URIs. It might as well be an URN 8-) > > Besides, writing log file entries is a change of state too; but > it's not a change of state that the client is accountable for. > > [[ > 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. > > ]] > -- 9.1.1 Safe Methods > http://www.ietf.org/rfc/rfc2616.txt > <- http://www.w3.org/2001/tag/doc/whenToUseGet.html Definitely. But any state change *could* be a problem, it's just up to the publisher to decide whether it's a problem for them or not, and obviously pretty much everyone agrees that a log file write isn't a problem for them (or if they did, they'd simply turn off logging). And if they decide that it is a problem, one of the most important tools at their disposal is to decide not to mint a URI. As-is, the protocol document says that the GET binding SHOULD be used (as the URI-length exception doesn't hold). While I'm ok with SHOULD, I think it would be useful to point to section 3.1 and say that some of the conditions there constitute a burden that some may not want to bear, and that this is also a reason to use POST. I think I'm repeating myself now, so you've likely heard the last from me on this topic. Cheers, Mark.
Received on Thursday, 19 January 2006 21:08:43 UTC