- From: <ccjason@us.ibm.com>
- Date: Tue, 12 Oct 1999 19:04:54 -0400
- To: w3c-dist-auth@w3.org
It looks like "everyone" is against error response minimization for PROPPATCH.
Can we get this listed in the spec?
How about...
Was...
8.2.1 Status Codes for use with 207 (Multi-Status)
The following are examples of response codes one would expect to be
used in a 207 (Multi-Status) response for this method. Note,
however, that unless explicitly prohibited any 2/3/4/5xx series
response code may be used in a 207 (Multi-Status) response.
Insert before the first paragarph....
The response to a PROPPATCH SHOULD always be 207 (Multi-Status). No error
minimization should be performed... even if all of the set and remove
operations
succeeded. This even applies to 200 (OK) response codes.
I said SHOULD and not MUST because of protocol situations... like the resource
isn't found. Am I correct? Or is it *always* going to be Multistatus?
The problem I have with the above phrasing is that it might make it sounds like
the following
error minimization isn't allowed and I suspect it is...
<D:propstat>
<D:prop><R:DingALing/><R:Random/></D:prop>
<D:status>HTTP/1.1 403 Forbidden</D:status>
<D:responsedescription> The user does not have access to
the DingALing property.
</D:responsedescription>
</D:propstat>
Are we prepared to eliminate this minimization? (I am.)
Also note... if we say there is no minimization... that means even if the
PROPPATCH had to back out everything due to one error, the response will still
need to list all those 200's along with the single error that occured. Does it
sound fine to outlaw the elmination of those 200's?
And a tangent...
Also, we don't say if a proppatch request can set a property several times. I
guess it's implicit that it can. That does make for somewhat more complex
server response generating code... unless we're going to allow each properties
to generate more than one response if altered multiple times.
Comments?
J.
Received on Tuesday, 12 October 1999 19:00:39 UTC