409 Conflict on double PUT?

1
votes

HTTP PUT spec says:

If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.

In my (WebDAV-like) API, I find it more user-friendly (and simpler to implement) to avoid replacing an existing object on consecutive PUTs, and rather explicitly err out with 409 Conflict or 405 Method Not Allowed. Does that violate the above RFC?

I find it strange that WebDAV implementations I've tried return 204 No Content on double PUT of file but 405 Method Not Allowed on double MKCOL of dir. Any reason for such inconsistency?

1
resthttphttp-put
I presume the implementations you've used do actually support double updates if they return 204? Otherwise the API is misleading... – James
Yes, WebDAV does support double update. But in my API I'd rather forbid them, -- if that doesn't go against the specs. – Andrey Paramonov
Can you clarify what exactly you mean by "double PUT", and why you think there's a problem with that? – Julian Reschke
PUT just has the semantics of replacing the current representation with the one provided in the payload. So if you send the same payload multiple times (multi-put) you'll end up with the same result anyways unless you use etags or other conditional requirements. It's in general advisable to stick to the protocol and return a 200/204 in case of a multi-put IMO. 405might yield the impression, that this operation is in general not supported, which is wrong per se. 409 might be a solution to your problem if you decide not to accept the same content again – Roman Vottner
@AndreyParamonov - well, PUT is create-or-update. You can restrict it on the server if you want, but it's certainly uncommon. – Julian Reschke

1 Answers

0
votes

PUT petitions are idempotent. A double PUT should probably have the same effect as a single PUT.