I guess it (post) is not idempotent. On the following pages in the
book it gets quite clear on that point. Sorry for the bandwidth use,
but it is confusing when two opposite things are said, though the book
seems quite good otherwise.

The most important thing about idempotent operations is that it's OK to do it a
second time (or third...) if you are not sure whether it worked the first time.

Example of an idempotent operation:

   x = 33;

Example of a non-idempotent operation:

   x += 33;

So, a web client can safely resend a PUT request automatically if there seems
to be a problem with the Net, but it must not do so automatically for a POST,
since that might, for instance, end up with the user buying several oil tankers
instead of just one.

   -- chris

It's in the errata.

{114,116}  Answer to Sharpen your pencil at bottom of page 114;
"POST is considered idempotent by the HTTP 1.1 spec."
should be:
"POST is not considered idempotent by the HTTP 1.1 spec."

http://www.oreilly.com/catalog/headservletsjsp/errata/headservletsjsp.confirmed

Idempotent means that only the first post may (but need not) alter
state. So you could have a URL representing a particular game of chess,
and add to that a move number and move. Technically that move could be
submitted with a GET, having the effect that that move is made permanent
and the next move must have the next move number and a valid move given
the previous moves.

However, various bits of software may well decide to load linked pages
into a cache without user intervention. Therefore it's generally best to
keep it simple, using GET only for side effect free operations and POST
for state change operations. A useful technique is to respond to a POST
with a redirect, meaning that the resulting page can be reloaded with
GET multiple times.

Tom Hawtin