If the Atom server is allowed to make changes to the posted entry,
such as dropping extension elements or adding or reordering stuff,
there probably needs to be some way to let the client know.
Alternatively, there could be some statement generally that "clients
MUST NOT assume that the server stored the entry as requested, and
thus MUST retrieve the newly-created entry if the client wishes to
have an accurate offline representation of the entry."
(Personally I feel it's a mistake not to require servers to store
extension elements. Yes, it's work for the server, but think of how
this could be used in 10 years if it's as successful as I suspect it
will be. Many conceivable extensions can work between clients, with
no new code required on servers, provided the server faithfully
stores and provides the extension data as part of the feed/entry.)
Lisa
On Jun 13, 2006, at 8:51 PM, Mark Baker wrote:
On 6/14/06, Joe Gregorio <[EMAIL PROTECTED]> wrote:
On 6/13/06, Mark Baker <[EMAIL PROTECTED]> wrote:
> If it's not capable of storing entities as requested, then it
> shouldn't send a successful response message to a PUT request,
since
> that's what PUT means.
I'm sorry but there is nothing in RFC 2616 that
calls for a 'byte-for-byte' interpretation of PUT.
And since the APP is not a 'must-understand' protocol
there is nothing wrong with a server ignoring foreign
markup.
I didn't say byte-for-byte.
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.
