Lisa Dusseault wrote:
Can a server ever ignore part of an edit and successfully process the
rest?
Yes. Think of a client that throws in a slew of random link elements with
relations my server implementation doesn't understand. Same with foreign
markup. The server is in charge.
I completely disagree with this. It is way too unpredictable for
clients to deal with. Clients are left with the illusion of flexibility
-- it *seems* you can use Atom syntax extensions and do creative things
that other extended clients can understand -- but in fact the server can
alter this at will leaving the client without any control over what it's
really publishing. In many cases, the client won't even want the server
to store some stripped version of what it POSTed, because it can really
change the meaning of some entry to have the server strip some of the
content and markup. Imagine removing the start time and location when
I'm trying to publish an event entry to what I believe ought to be a
calendar feed.
Some server changes to submitted documents is of course going to be
allowable (edit dates, server-provided IDs, changes which are
effectively XML canonicalization) but I believe these need to be
limited. The general case, which is how servers deal with unrecognized
elements, needs to be severely limited so that the server can either
reject the whole request or store as provided.
I believe I first saw this in a response made by Roy Fielding to an
assertion that servers must treat HTTP PUT as a bit-for-bit copy, but I
can't immediately find the reference. In any case: clients must always
consider the possibility that the server processes other requests (even
internally generated ones) between the time the one the client issued
and the next request the server choses to process. Such requests could
partially or completely change the representation of the resource.
- Sam Ruby
