< Game Non-Design
Request Weblog #3: Game Non-Non-Design >

[Comments] (6) Lost Update Nanny State: In the web service I'm working on, we're considering rejecting PUT and PATCH requests unless they're accompanied by a valid If-Unmodified-Since or If-None-Match. Basically forcing clients to consider the lost update problem and work with us to avoid it. If you're trying to PUT a new resource, you need to send If-None-Match: * to avoid stepping on someone else who just created that resource.

Is this legal? Seems okay to me, but I'm not sure what response code to send. 412 ("Precondition Failed") is the obvious choice, but the precondition that failed is that the client didn't specify a precondition, and that's weird. I see that the Astoria team is thinking about the same things (search for "validation during side-effecting operations").


Comments:

Posted by Aristotle Pagaltzis at Wed May 14 2008 01:31

It’s definitely legal to reject a request on the basis of whatever criteria you deem sufficient.

There does in fact seem to be no good response status, though. Maybe 409 Conflict? You could think of all update requests as conflicting with the current state of the resource, unless the client happens to certify the update as being applicable. That too is weird, though – just in a different way from 412.

I looked at WebDAV, but at best that offers 423 Locked. But not only is that one wrong even after squinting, it also mandates a response body that makes sense only in the context of WebDAV.

No other 4xx status is even vaguely right.

Overall, I think I very slightly prefer the weirdness of 409 over that of 412.

Posted by Subbu Allamaraju at Wed May 14 2008 10:28

It is not only legal, but also recommended for PUT, PATCH and DELETE as well.

IMO, 412 is the most appropriate error, since these are conditional requests.

Posted by Leonard at Wed May 14 2008 15:05

Subbu, you speak like one who has encountered authority. Who recommends it? Also, I like your weblog.

Posted by Aristotle Pagaltzis at Wed May 14 2008 23:27

Subbu: I thought the issue at hand is precisely the requests that are not conditional. Leonard wants to reject all requests that do not declare preconditions.

David: If you take that text literally, that would mean you could never use 409 in any protocol intended for programmatic clients. I don’t think that was really the intent. The point I take away from that sentence in the spec is that 409 is an explicit “fix your request and try again” prompt to the client, as opposed to things like 403 in which the server explicitly says “go away and don’t try again, I’m not changing my mind.”

Hm.


[Main]

Unless otherwise noted, all content licensed by Leonard Richardson
under a Creative Commons License.