I'm sorry, but that's not what rfc2616 says. ...the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server...
...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... ...HTTP/1.1 does not define how a PUT method affects the state of an origin server.... You're right about there not being any grey area here. The server SHOULD return a 200 or 204 only if the resource has been modified as a result of the PUT operation. There is no requirement that the modified resource be semantically identical to that included in the PUT request. - James Mark Baker wrote: >[snip] > It's simply a matter of whether the server can do what the client > asked of it. In order to answer 2xx to a PUT, the server needs to > have set the state of the identified resource to that represented by > the entity body in the request. As the extension in question is part > of what the client is asking to be stored, the server can only ignore > it if it knows it to be a no-op, just as if it were whitespace as Rob > points out. > > Luckily, there's no grey area here that I'm aware of. > > Mark. > >
