- From: <bugzilla@soe.ucsc.edu>
- Date: Wed, 8 Feb 2006 10:14:58 -0800
- To: w3c-dist-auth@w3.org
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=211
ejw@cs.ucsc.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|elias@cse.ucsc.edu |lisa@osafoundation.org
------- Additional Comments From ejw@cs.ucsc.edu 2006-02-08 10:14 -------
Discussed this during the Feb. 8, 2006 teleconference.
We discussed the handling of errors in situations where a client requests a
cross-server COPY/MOVE. This situation is as follows:
client --> server A --> server B
The client makes a cross-server COPY/MOVE request to server A. This request asks
server A to COPY/MOVE one or more resources to server B. There are two broad
error cases here.
1) The original origin server (server A) just plain does not implement
cross-server COPY/MOVE. It has no mechanism for executing this functionality. In
this case, we agreed that the original origin server (server A) MUST fail the
request, and SHOULD return a 501 (Not Implemented), with a <DAV:error> code that
indicates this error situation.
2) The original origin server (server A) does implement cross-server COPY/MOVE
functionality (perhaps with WebDAV, perhaps using some other protocol), and
attempts the requested COPY/MOVE. The follow-on server (server B) is unable to
fulfill this request, and hence server A now needs to tell the client that their
request was not fulfilled. Ideally, server A should report that there was a
cross-server operation error (perhaps using a new status code (5xx series most
likely), and then also indicate the problem faced by the follow-on server. That
is, server A would essentially be packaging the error reported by server B, and
sending it along to the client. If server A and server B are communicating using
WebDAV, then this is fairly easy -- we just use a variant of the PROPFIND
response XML packaging for reporting errors. If server A and server B comunicate
using some other protocol, the best we can do is create a generic envelope,
label the kind of error response, and leave it to the client to figure out
what's going on. Alternately, we could define some broad categories that server
A would use to map the errors into.
In any event, it should be clear there are a number of issues involved in
propertly reporting cross-server operation errors. These are part of a larger
collection of issues surrounding cross-server operation behavior in general. It
would be best to have a separate effort that addressed these issues
substantively, and we should leave the error reporting in this situation
undefined, so that this future effort has a blank slate for designing
appropriate error reporting.
Therefore, in this situation 2518bis should state that the error reporting for
case #2 is intentionally undefined.
Assigning to Lisa to add text into the specification.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
You are on the CC list for the bug, or are watching someone who is.
Received on Wednesday, 8 February 2006 18:15:07 UTC