W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2004

Re: Using error response bodies for more information

From: Geoffrey M Clemm <geoffrey.clemm@us.ibm.com>
Date: Sun, 11 Jul 2004 17:02:36 -0400
To: " webdav" <w3c-dist-auth@w3.org>
Message-ID: <OF382596A0.16247E1A-ON85256ECE.007386C4-85256ECE.0073AC71@us.ibm.com>
I agree with all of Julian's comments in this message.


Julian wrote on 07/11/2004 03:30:48 PM:
> Lisa Dusseault wrote:
> > There have been a number of discussions about using the error response 

> > body, as DeltaV and ACL do, in RFC2518bis. Some of the cases where 
> > has been suggested:
> >  - If the XML sent to the server refers to external entities, the 
> > would respond with 403 Forbidden with 'forbid-external-entities' in 
> > body.
> >  - A 423 Locked response could include the lockdiscovery property 
> > in the response body (including the lock token, timeout, owner, etc 
> > client use)
> >  - A LOCK refresh or UNLOCK request was addressed to a Request-URI 
> > did not fall in the scope of the lock identified by the Lock-Token 
> >  - An UNLOCK request not containing a lock token at all
> >  - Clarify 409 error to PUT or MKCOL saying that the parent collection 

> > does not exist.
> >  - MOVE error response when the source and destination URLs are on 
> > different servers or different subnamespaces on a single server
> > 
> > I would like to confirm that we want to go down this path, because it 
> > involves new specification writing, more decisions, more changes, and 
> > effort to maintain consistency with conflicting examples. For example, 

> Definitively.
> > should the new requirements be consistent with DeltaV and ACL in using 

> > only 403 and 409 with precondition/postcondition responses, or should 
> > they be consistent with RFC2518 original status codes and include 
> > with errors like 423 Locked and 400 Bad Request?   Would these be 
> Yes. They should allow any 4xx (or 5xx for that matter). Note that we'd 
> be making this extension in BIND already if we needed it there.
> > requirements or MUST (in order to allow clients to rely on the 
> > additional information more quickly)?
> I think at least for RFC2518bis they should be "SHOULD" level 
> requirements. We don't want servers to become non-compliant if they 
> don't support this (in fact I want Apache/moddav to be conformant with 
> as little changes as possible!). No big harm is done when the response 
> bodies are missing; after all it's just a feature that allows better 
> recovery from error conditions and better diagnostics.
> > Please respond with your opinion and further discussion,
> I'd like to point out once more that if a spec adopts the DAV:error 
> syntax, it should be consistent in it's usage with RFC3253 (namely that 
> the XML element names we use name *preconditions* and *postconditions* 
> not problems).
Received on Sunday, 11 July 2004 17:15:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:06 GMT