2006/6/14, Mark Baker <[EMAIL PROTECTED]>:
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.
But HTTP is a stateless, disconnected protocol, so you can't be assured that nobody updated the resource between your PUT and your subsequent GET, "nobody" being another user, a process launched as soon as the resource has changed, a job started every hour or so, etc. So what if I write a server implementation where I first store "to disk", lock the resource (any request is pending until the unlock), launch a process to strip some undesired markup and then unlock the resource (if you requested the resource diring the lock, you'd have waited 'til now, and you are sent the modified resource)? The process could take some milliseconds or so and you might not even notice the resource was locked. This would not apply however to the entity sent in response to the PUT… Please note also that HTTP/1.1 says in the PUT method definition:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
and then:
Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.
Entity headers are *part* of the entity, and HTTP/1.1 explicitly allows servers not to store them in certain circumstances (so you might do a PUT with an entity header, GET the resource and notice the header isn't there so try the PUT again, all the day long). Why couldn't APP define such a rule for foreign markup and some Atom elements in application/atom+xml entities? I suggest APP should do that and simply be silent for entities of other media types (because HTTP already takes care of it). For example: Markup from non-Atom vocabularies and recognized markup from the Atom vocabulary in application/atom+xml entities in a PUT request SHOULD be stored along with the resource modified by the PUT. Unrecognized markup from the Atom vocabulary in application/atom+xml entities in a PUT request MUST be treated as an error. Servers are expected to use a 422 (Unprocessable Entity) or 400 (Bad Request) status code for such errors. Any attempt to change the value of atom:id [EMAIL PROTECTED]@ add other elements here as needed]] MUST equally be considered an error. Servers are expected to use a 409 (Conflict) or 400 (Bad Request) status code for such errors. -- Thomas Broyer
