Re: Using error response bodies for more information

I agree with all of Julian's comments in this message.

Cheers,
Geoff

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 
this 
> > has been suggested:
> >  - If the XML sent to the server refers to external entities, the 
server 
> > would respond with 403 Forbidden with 'forbid-external-entities' in 
the 
> > body.
> >  - A 423 Locked response could include the lockdiscovery property 
value 
> > in the response body (including the lock token, timeout, owner, etc 
for 
> > client use)
> >  - A LOCK refresh or UNLOCK request was addressed to a Request-URI 
which 
> > did not fall in the scope of the lock identified by the Lock-Token 
header.
> >  - 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 
an 
> > 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 
bodies 
> > with errors like 423 Locked and 400 Bad Request?   Would these be 
SHOULD 
> 
> 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).