Tclers Wiki spurious self-conflict on editing about wikitcl HOT 6 CLOSED

I went back, after filing this bug, and took a look at the delta. Indeed, 
between my
pressing the save button and the appearance of the Edit conflict, a second 
change
occurred on the page. Thus, it appears the file locking mechanism is not 
working as
expected.

Datapoint extra detail.  There's a little debugging narrative created at 
conflict,
which reads "error @@Conflict on Edit: '1182262419 [email protected]' ne
'1182263177 [email protected]'" in this case.

The save request contained '1182262419 [email protected]' (being the time the
version you edited was saved and person who saved it) but the value read from 
the
database for the saved record (immediately prior to the attempt to save) was
'1182263177 [email protected]', which is a later time!  I'm not yet sure how 
those
values got to the db - unless (somehow) the request is being processed twice.

This is an intriguing possibility.

I get the feeling the edit conflicts are time related - i.e. the faster I get 
to the
Save button, the more likely they are. If I deliberately go away and do 
something
else, then come back to press Save, I never get a conflict (except the time I 
got a
real one :-) ).

I've added code to detect a self-conflict, log it, and just drop the change on 
the
floor (that is, refuse to add it) after logging the conflict.

This is a stop-gap aimed at minimising annoyance and flushing out two possible 
causes:

1) the client or proxy is sending the POST twice
2) the server is handling the POST twice, despite only getting it once.

In case (1) the edit change will be reflected in the page.
In case (2) the edit change will not be reflected in the page.

I'm hoping, thereby, to test the hypothesis as to cause.

Found the problem: I was sending a 302 response to a POST, but should have been
sending a 303.  Solution suggested by
http://osdir.com/ml/web.blogger.api/2004-04/msg00009.html