On Fri, 2002-04-26 at 09:39, Kendall Clark wrote: > >>>>> "terrel" == Terrel Shumway <[EMAIL PROTECTED]> writes: > > Hmm, once more: GET is supposed to be idempotent *and* safe. > > terrel> I agree. GET should be idempotent unless there is a clear > terrel> indication otherwise such as > terrel> "/?action=this+will+change+your+document+forever" or > terrel> "/?bill=charge+my+visa&amount=5+zillion+dollars" > > Those are idempotent, afaict. :> > > Idempotent doesn't mean 'side-effect free'; it means "repeated > applications have the same effect as the first one" (for some pretty > vaguely undefined time span, though).
idempotent adj. Acting as if used only once, even if used multiple times. F:V->V is idempotent iff F(F(v))=F(v) for all v in V e.g. F(x)=x*1, F(x)=x*0, F(x)=c, F(x)=x+0, are idempotent, but F(x)=x+1 is not. DELETE is idempotent (once it is gone, it is gone), but charging a credit card is not. Unfortunately, http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2.2 does claim that idempotent means "side-effect free" when describing when to use POST vs GET in html forms. This MIGHT be why RFC 2068 even mentions "Idempotent Methods"-- to clear up the confusion. RFC 2068 (section 9.1) is correct, in the use of idempotent vs safe methods, and the emphasis that GET and HEAD should always be 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. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 9.1.2 Idempotent Methods Methods may also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Thank you, Kendall, for helping me to clarify this in my mind. Idempotence is not the issue, safety is. Therefore, a servlet that would otherwise perform an unsafe action SHOULD NOT do so if the HTTP request method is GET or HEAD. -- Note: GET side-effect as a feature: Counters are the best example. Counters don't work if the UA considers GET idempotent and optimizes away repeated requests for the same resource. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
