Subject: new issue: requirements on dav:error responses

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Nov 2006 12:33:00 +0100

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 01:18:44 +0100

Wilfredo Sánchez Vega schrieb:
>   My server does, in fact, return XML for (eg. ACL) errors to GET, and, 
> of course, it looks kinda stupid in my browser.  In this case:
> 
> <?xml version='1.0' encoding='UTF-8'?>
> <error xmlns='DAV:'>
>   <need-privileges>
>     <resource>
>       <href>/principals/user/wsanchez</href>
>       <privilege>
>         <read/>
>       </privilege>
>     </resource>
>   </need-privileges>
> </error>
> 
>   The browser simply shows the string "/principals/user/wsanchez".
> 
>   I'm not terribly excited about returning HTML instead, however, since 
> that's less useful for my primary clients.  If I did, I'd do it based on 
> user-agent strings, which is stupid in other ways, but at least only 
> exposes HTML to (the subset of) clients that I know don't care about the 
> XML error.
> 
>   Instead, I was wondering recently whether inserting an XSL stylesheet 
> into the DAV XML response would help here.  It would be one of those 
> <?blah?> elements:
> 
> <?xml version='1.0' encoding='UTF-8'?>
> <?xml-stylesheet type="text/xsl" href="foo.xsl"?>
> <error xmlns='DAV:'>
>   <need-privileges>
>     <resource>
>       <href>/principals/user/wsanchez</href>
>       <privilege>
>         <read/>
>       </privilege>
>     </resource>
>   </need-privileges>
> </error>
> 
>   I don't really have clue enough yet to write a stylesheet, but it 
> seems like it might work...
> 
>   (Yes, I'd be happy enough even if it means that browsers that don't 
> understand XSL stylesheets remain broken.)

That's actually a very good idea. I personally wouldn't worry about 
non-XSLT aware browsers anymore. The good question is whether browsers 
do the "right thing" even if the status code wasn't 2xx.

Something to try out. But I'd still rather not require servers to do that.

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 28 Nov 2006 17:34:14 -0800

Yeah, it's always hard to get the wording of these just right.  We  
might have been better off saying in the first place "When used, the  
XML element MUST appear inside...."   That would cover both the  
"UNLESS otherwise negotiated" and the "UNLESS in response to GET"  
cases.  We have this wording problem a lot, particularly describing  
error responses.  Like "If the client doesn't have the permissions to  
do the action the server MUST return 403":  well, UNLESS there's an  
even higher-level error, like the syntax was wrong or the server is  
down for maintenance!

I'd like to think that implementors are smart enough to understand  
the implied exceptions -- the "UNLESS..." -- in these kinds of  
requirements.  But I'll admit that occasionally list arguments crop  
up about strictly enforcing without taking into account the implied  
exceptions.  Are these just arguments on the list or is there some  
non-rare cause of  implementation errors?  Can we even hope to think  
of all the reasonable exceptions?  Is there a better pattern of  
English statements to use that allows exceptions without stating them  
all -- and if so can we use it in the future (but maybe not now)?

Thanks,
Lisa

On Nov 28, 2006, at 3:33 AM, Julian Reschke wrote:

> <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."
>
> 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
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 29 Nov 2006 09:55:50 +0100

Lisa Dusseault schrieb:
> Yeah, it's always hard to get the wording of these just right.  We might 
> have been better off saying in the first place "*When used*, the XML 
> element MUST appear inside...."   That would cover both the "UNLESS 
> otherwise negotiated" and the "UNLESS in response to GET" cases.  We 
> have this wording problem a lot, particularly describing error 
> responses.  Like "If the client doesn't have the permissions to do the 
> action the server MUST return 403":  well, UNLESS there's an even 
> higher-level error, like the syntax was wrong or the server is down for 
> maintenance!

I think that after all, we are specifying something which is really 
optional, at least for GET. Throwing in normative requirements here 
doesn't really help; I can easily imagine cases where somebody returns 
XHTML, and wants to embed DAV:error somewhere in the response document. 
Would that really violate a MUST level requirement? I don't think so; it 
just means that a client written to *this* spec won't see it.

So why don't we just specify the format (multistatus/non-multistatus 
case), and leave it at that?

> I'd like to think that implementors are smart enough to understand the 
> implied exceptions -- the "UNLESS..." -- in these kinds of 
> requirements.  But I'll admit that occasionally list arguments crop up 
> about strictly enforcing without taking into account the implied 
> non-rare cause of  implementation errors?  Can we even hope to think of 
> all the reasonable exceptions?  Is there a better pattern of English 
> statements to use that allows exceptions without stating them all -- and 
> if so can we use it in the future (but maybe not now)?

The issue came up over here because my colleague stumbled upon the 
similar requirement in RFC3744 which obviously is not implementable. If 
this applies to RFC3744, it applies to RFC2518bis as well. And as this 
is *new* stuff (not inherited from RFC2518), we really should get it 
right. Or are we already planning for the next revision?

Best regards, Julian