News You Can Bruise for 2008 May 13

Permalink [Comments] (6) Tue May 13 2008 21:12 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 Stefan Tilkov at Wed May 14 2008 01:59

I agree with Aristotle: 412 says "The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server", which is clearly not the case in your example. 409's definition is general enough to be interpreted according to your needs :-)

But it seems there really should be an official response code for this purpose.

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 David Terrell at Wed May 14 2008 10:54

409 expects the end user to be able to resolve the error, while this is clearly a tool error:

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.

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.

Leave a comment