Subject: Using error response bodies for more information

From: Lisa Dusseault <[email-masked]>
Date: Sun, 11 Jul 2004 12:02:16 -0700

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, 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 requirements or MUST (in order to allow clients to rely 
on the additional information more quickly)?

Please respond with your opinion and further discussion,
thanks,
Lisa

---

From: Julian Reschke <[email-masked]>
Date: Sun, 11 Jul 2004 21:30:48 +0200

Lisa Dusseault wrote:

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

Best regards, Julian

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

---

From: Geoffrey M Clemm <[email-masked]>
Date: Sun, 11 Jul 2004 17:02:36 -0400

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

Cheers,
Geoff

> >  - If the XML sent to the server refers to external entities, the 
server 
> >  - A LOCK refresh or UNLOCK request was addressed to a Request-URI 
which 

> > involves new specification writing, more decisions, more changes, and 
an