On 6/14/06, James M Snell <[EMAIL PROTECTED]> wrote:
RFC2616 does not dictate what the server must store. Servers are free to store whatever they want. If the client PUTs "Foo" and the server stores "Bar", it's still a valid HTTP PUT request even if it's not what the client expected.
Let's be careful, because there's two different aspects of the server's behaviour in play here, and they seem to be getting confused. If the HTTP server wants to stick "Bar" in a (say) file as a result of a PUT "Foo" request, that's fine, as the snippet below makes clear (at least how I interpret it, since I wasn't present when it was added to the spec). But if it does that, it has to be treat "Bar" as a serialization of the semantics of "Foo", and be able to reverse that transformation when interacting with clients using that resource (to the extent defined by the media type - i.e. it need not be an entirely lossless transform). That's required because, again, the meaning of PUT is store, and if you respond to a store request in the affirmative, you better darned well have stored the thing.
<snip> HTTP/1.1 does not define how a PUT method affects the state of an origin server. </snip>
Mark.
