[Zope-dev] RFC 2616, side effects, and idempotence (was: Last-Modified....)

[R. David Murray]

On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
> Toby Dickenson wrote:
> >>  Rendering may produce side effects. But "HEAD" requests
> >>  are required by HTTP not to have side effects.
> >
> > RFC 2616 section 9.4 states that "HEAD" is identical to "GET" in this respect,
> > and both should have no side effects.

This bugged me the first time this discussion went around, and I
feel impelled to clearify it now, even though it is a little
tangential to the core of the discussion.  I guess I'm just a
precisionist when it comes to terminology <grin>.

The RFC does *NOT* say that GET and HEAD must have no side effects.
That is just the simplist implementation of what it *dees* say,
which is that GET and HEAD must be "idempotent".  When Tim (I think it
was) mentioned this in the first round of this disucssion, I had to look
it up even though it is a good math term and I was a math major.

What it means is that once you do a GET or HEAD request, any
*subsequent* GET or HEAD request for that same URI may not change the
state of the system.  But the *first* access to that URI *can* change
the state of the system.  (See section 9.1.2.)

So it seems to me that some of the concern I have seen in Zope code
with avoiding "write on read", where a GET request would otherwise
trigger the one-time initialization of something in the database,
is misplaced if the concern that motivates it is adhering to this
spec.  There may well be other reasons to wish to avoid idempotent
write-on-read (although I haven't thought of any yet), but RFC 2616
isn't one of them.

NB: There seems to be a small bug in the spec, in that it does not say
that any sequence of GET and HEAD requests on the same URI should
be idempotent, but that is clearly the intent.

--RDM

PS: somehow, I don't think the spec writers thought
much about hit counters...