Re: BIND and HTTP status codes

Julian Reschke wrote:
> 
> Hi,
> 
> while implementing WebDAV BIND in Jackrabbit [1] (the Apache Java 
> Content Repository Reference Implementation), my colleague Manfred 
> Baedke noticed that the spec currently micro-manages HTTP status codes: 
> for instance, for a successful BIND it requires status codes of 200 or 
> 201, while - from an HTTP point of view - a 204 should be acceptable as 
> well.
> 
> Proposal: rephrase the text so that other success codes are acceptable 
> as well, or remove the normative language completely, point to RFC2616, 
> and rely on examples.
> 
> BR, Julian
> 
> [1] <https://issues.apache.org/jira/browse/JCR-1733>

Proposed resolution, deliberately kept simple in order not to make 
bigger changes at this stage:

Section 4., paragraph 9:
OLD:

       If the request succeeds, the server MUST return 201 (Created) when
       a new binding was created and 200 (OK) when an existing binding
       was replaced.

NEW:

       If the request succeeds, the server MUST return 201 (Created) when
       a new binding was created and 200 (OK) or 204 (No Content) when an
       existing binding was replaced.


Section 5., paragraph 6:
OLD:

       <!ELEMENT unbind (segment)>

       If the request succeeds, the server MUST return 200 (OK) when the
       binding was successfully deleted.

NEW:

       <!ELEMENT unbind (segment)>

       If the request succeeds, the server MUST return 200 (OK) or 204
       (No Content) when the binding was successfully deleted.


Section 6., paragraph 7:
OLD:

       If the request succeeds, the server MUST return 201 (Created) when
       a new binding was created and 200 (OK) when an existing binding
       was replaced.

NEW:

       If the request succeeds, the server MUST return 201 (Created) when
       a new binding was created and 200 (OK) or 204 (No Content) when an
       existing binding was replaced.

See also 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.status-codes>. 
Note that I also added a Location header to the one example where a 201 
status is returned; this may be a good idea as the newly created URI != 
the request-URL (but I wouldn't want to normatively require it).

BR, Julian