Re: On pipelining -Reply

Miles Sabin wrote:
> 
> Christopher K. St. John wrote,
>
> > SHOULD (in the rfc2119 sense) is unfortunately the operative
> > word here. GET's idempotence is a SHOULD, not a MUST.
> > Reference rfc2616, section 9.1.1.
> 
> Not at all. I don't see anything there, or anywhere else, which
> states that GETs idempotence is optional.
>

 From section 9.1.1:

     "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."

 However, from section 9.1.2:

    "Methods can 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."

 Which, as I read it, says you are free to have GET requests change
server side state as long as the state changes are idempotent. (Although
9.1.1's language can easily be read as weakening that considerably)

 
> All it says is that GET "SHOULD NOT have any significance other
> than retreival". That's a *very* long way from permitting side-
> effects. It allows but discourages, for example, a server
> making a rude noise when it handles a GET ... but that's not
> state.
>

 So, a compliant implementation may have idempotent side effects,
but an unconditionally compliant implementation may not.

 Unfortunately, my experience with servlets and other application server
technologies leads me to believe that the "idempotent" requirement for
side effects is widely ignored (and not just for page counters) Not that
that's an excuse, just a data point :-)

 Thanks for the clarification,


-cks

Received on Friday, 21 January 2000 10:28:27 UTC