new issue: requirements on dav:error responses

Hi,

I just realized that an issue recently discovered for RFC3744 (see 
<http://www.lyra.org/pipermail/acl/2006-October/001918.html> and 
<http://greenbytes.de/tech/webdav/draft-reschke-rfc3744bis-latest.html#rfc.issue.7.1.1-error-body-vs-GET>) 
also applies to RFC2518bis.

Currently it says 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-16.html#rfc.section.16>):

"Each precondition and postcondition has a unique XML element associated 
with it. In a 207 Multi-Status response, the XML element MUST appear 
inside an 'error' element in the appropriate 'propstat or 'response' 
element depending on whether the condition applies to one or more 
properties or to the resource as a whole. In all other error responses, 
the XML element MUST be returned as the child of a top-level 'error' 
element in the response body, unless otherwise negotiated by the 
request, along with an appropriate response status. The most common 
response status codes are 403 (Forbidden) if the request should not be 
repeated because it will always fail, and 409 (Conflict) if it is 
expected that the user might be able to resolve the conflict and 
resubmit the request. The 'error' element MAY contain child elements 
with specific error information and MAY be extended with any custom 
child elements."

Note:

"In all other error responses, the XML element MUST be returned as the 
child of a top-level 'error' element in the response body, unless 
otherwise negotiated by the request, along with an appropriate response 
status."

The problem here is that for a simple "GET" request (without Accept 
header), a server implementor will always return HTML, otherwise he'll 
get lots of support calls. On the other hand, the "unless otherwise 
negotiated by the request" loophole doesn't really apply here.

Best regards, Julian

Received on Tuesday, 28 November 2006 11:33:08 UTC