- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Wed, 16 Oct 2013 11:47:28 +0200
- To: "Willy Tarreau" <w@1wt.eu>
- Cc: "cowwoc" <cowwoc@bbs.darktech.org>, "Martin Thomson" <martin.thomson@gmail.com>, "Mark Nottingham" <mnot@mnot.net>, "Julian Reschke" <julian.reschke@gmx.de>, "HTTP Working Group" <ietf-http-wg@w3.org>
Le Mer 16 octobre 2013 06:00, Willy Tarreau a écrit : > The main idea behind idempotence is to know whether or not a client can > safely resend a request that failed because of network errors. For > example, > sending a request over an established connection may result in an error if > the server decided to close at the same time. But the client has no way to > know if the request was considered or not, so it must resend it. If the > previous request was correctly processed, the second one may return an > error, but it's the client's job to handle this. I can give you an example > here with unix commands : I'm not sure I agree with the example, I've seen cases where idempotence is a much stronger property. For example, since GET is idempotent, that means a malware checker service can replay (before or after the browser) get requests to check if the result is dangerous or not. And it does not affect the result the browser will receive on its own GET. If you say mv is an example of idempotence, that means all the broken websites that transform GETs into implicit POSTs are right, since the first GET destroys the result the following GET could expect. IMHO idempotence means a replay of the same command will give the same result, baring errors, website reorganisations, and data changes (when the request exposes some dynamic data store) Regards, -- Nicolas Mailhot
Received on Wednesday, 16 October 2013 09:47:59 UTC