[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Meaning of PUT

So as an implementor who is mapping APP and Atom onto a pre-existing
relational data model, I would have to scan every entry in every request
for any elements and attributes my implementation is incapable of
storing rather than just looking for the bits and pieces I do understand
and am capable of handling, effectively rendering Atom's Must-Ignore
extension semantics absolutely useless to me as a server developer and
consuming additional server resources for what reason again?

Perhaps this would be an appropriate error message:

  "Although your request contains all of the information the server
   needs to perform the requested update operation, the request had to
   be rejected because there was additional stuff in the request that
   the server didn't understand and doesn't care anything about.  Of
   course, if it were up to us, we'd prefer to go ahead and process the
   update request because we really don't care that there's extra stuff
   in the request, but the APP spec says we have to reject it.  Strip
   out the parts we don't understand and try the request again..."

Lots of fun.

- James

Bill de hÓra wrote:
> Kyle Marvin wrote:
>> On 6/14/06, Robert Sayre <sayrer@xxxxxxxxx> wrote:
>>> Tim Bray wrote:
>>> >  I.e. in the first case, we're saying "Client: don't do this."  In the
>>> > second "Server: if the client stupidly requests this, ignore it."
>>> NO. -1. Do not design requirements for servers you know nothing about.
>>> Servers: send an error if a client sends a request you can't deal
>>> with. Do not silently "correct" the request. This is how HTTP works,
>>> it's a normative reference, don't rewrite some busted version in Atom
>>> Protocol. OK?
>> FWIW, this (Robert's interpretation) is the behavior we've opted for
>> the GData APP implementation.  If a client sends us extension elements
>> we don't persist with an entry (for example), we reject it with a Bad
>> Request http error.
>> [...]
>> Our design was based upon the the belief that if building a store then
>> accepting MOST of the client's data wasn't good enough.    It was all
>> or nothing.   Our definition of "correct" doesn't include silent data
>> loss.
> This is the behaviour I'd like to see. Can we document it ;)
> cheers
> Bill