[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meaning of PUT, with (gasp) evidence

On Jun 14, 2006, at 10:40 PM, James M Snell wrote:


OK, granted, Mark was (apparently) seriously proposing that the GData behavior be made compulsory.

Frankly, I didn't take those posts seriously. In the real world, publishing system servers are just not going to blindly live with an either-copy-it-in-exactly-as-sent-or-declare-failure dichotomy. Just won't happen. If we really truly believe that this the correct interpretation of PUT, then PUT is violently unsuitable for use in the APP. And, for that matter, in any other general-purpose publishing protocol.

Fortunately, that's not what the RFC says. I just re-read RFC 2616, section 9.6. It says very clearly that a PUT "requests that the enclosed entity be stored under the supplied Request-URI". Nowhere does it say that the server is forbidden to interpret that request... moving on a bit, we find "If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request." Do we find any language saying that to be considered successful, the modification has to consist of an exact slavish copying-in of the data as requested by the client? No. If the server took the request seriously enough to act on it, as opposed to punting it - defined by it being willing to modify the resource - then that is success. This *totally clearly* neither forbids nor mandates what Google is doing.

So can we drop this stupid debate already? MarkB's proposed interpretation of PUT is unsupported by the normative specifications and is violently incompatible with publishing-system reality.

But, since we're quoting RFC2616 chapter and verse, I note the following: "If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. " I take that to imply that sending a PUT to the edit URI of an Atom Entry MUST NOT change the atom:id.