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

2002-06-18 Thread 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...



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

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

2002-06-18 Thread R. David Murray 

On Tue, 18 Jun 2002, Oliver Bleutgen wrote:
 First, your quoting is wrong, I didn't write that - talk about
 precisionist *g*.

Check the number of s.  I don't know who lost the attribution
of the inner part, but I just replied to your message and
cut off everything after the last line quoted.  The joys of
email grin.

 But, there's also the attribute safe, which is described in 9.1.1:
[...]
 Which is IMO exactly what we were talking about in that thread.

Good point.

 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

It's not in the one example I could quote you, in Z3 (some hoops
Casey jumped through to try to get the first call to look up a
non-existent annotation in an AttributeAnnotatable from causing
a ZODB write).  But in other cases it might well be.

In light of the hit counter use case, safety probably is much more
important than idempotence.

--RDM



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )