Re: URI serialization issues

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