Re: Meaning of PUT, with (gasp) evidence

[Tim Bray <Tim.Bray@xxxxxxx>]

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

> http://www.imc.org/atom-protocol/mail-archive/msg05349.html
> http://www.imc.org/atom-protocol/mail-archive/msg05352.html
> http://www.imc.org/atom-protocol/mail-archive/msg05357.html

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.

 -Tim