Re: Using error response bodies for more information

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,
> thanks,
> Lisa

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


Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Sunday, 11 July 2004 15:31:30 UTC