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

[Oliver Bleutgen]

R. David Murray wrote:
> 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.
>>

First, your quoting is wrong, I didn't write that - talk about 
precisionist *g*.


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

This doesn't cover everything.
First, you're right, the RFC indeed doesn't say MUST anywhere concerning 
the areas we are talking about. This is important. Zope does not violate 
the RFC.
But, the RFC introduces two, let's say attributes to methods.
One is idempotent, which is described in 9.1.2 which you righlty refer to.

But, there's also the attribute safe, which is described in 9.1.1:

9.1.1 Safe Methods

    Implementors should be aware that the software represents the  user
    in their interactions over the  Internet, and should be careful  to
    allow the user to be aware of any actions they might take which may
    have an unexpected significance to themselves or others.

    In particular, the convention has been established that the GET and
    HEAD methods SHOULD NOT have  the significance of taking an  action
    other than retrieval. These methods ought to be considered  "safe".
    This allows user agents to  represent other methods, such as  POST,
    PUT and DELETE, in a special way, so that the user is made aware of
    the fact that a possibly unsafe action is being requested.

    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.

Which is IMO exactly what we were talking about in that thread.

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

Perhaps it is. I don't know the areas of the code where you have seen 
that, but it might be inspired not by the problem of idempotence, but of 
"safeness"


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

Lol, I think so too.

cheers,
oliver