Description: ------------ The only chance to report a server error on PROPFIND requests is to return false from the PROPFIND() method. But http_PROPFIND() only returns a 404 in this case, while there might be different error situations, e.g. accessing a restricted folder where we might want to return a 403 error. It would be good if one could return custom error headers like from the GET() methods.

The status code for a PROPFIND should always be 207 on success, on hard errors it probably return a 500 "internal server error" instead of a 404. Codes like 200, 401, 404 related to requested resource URLs should be returned within the <status> fields of the XML <response>, not in the HTTP header itself. The <status> content is hard coded as 200 right now though, so i'm leaving this bug open for now, i'll just fix it in a different way ...

thinking again the <status> in the XML response is about properties, not resources ... Both RFC2518 and the WebDAV book are pretty vague on this, only mentioning the success case (207) but not the possible errors ... Need to check mod_dav behavior on this and the draft for the new WebDAV RFC ...

The way i read RFC 4918 for now is that a PROPFIND may only return 403 if 403 Forbidden - A server MAY reject PROPFIND requests on collections with depth header of "Infinity", in which case it SHOULD use this error with the precondition code 'propfind-finite-depth' inside the error body. so this would be a thing to keep in mind when moving from RFC 2518 to 4918 The way i understand 403 would be handled for resources in general is to create a <propstat> block with all properties listed as 403 for a forbidden resource ... which i need to implement support for, too

The way I read RFC2518, section 8.1 ("PROPFIND") it seems to me the possibility exists to be able to send errors other than 404. From the document: "If there is an error retrieving a property then a proper error result MUST be included in the response." I agree the document is ambiguous and it seems that the only anticipated error is one of 403, 404, or 500. But the statement about a "proper error result" appears to me to open the door to handling other error conditions. To support this theory, the following is taken from section 9.1.2 (the section defining response codes for PROPSTAT) of RFC 4918: "...however, clients should be prepared to handle other 2/3/4/5xx series status codes as well."