BIND and HTTP status codes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

BIND and HTTP status codes

Julian Reschke

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>

Reply | Threaded
Open this post in threaded view
|

WebDAV BIND support in Apache Jackrabbit, was: BIND and HTTP status codes

Julian Reschke

Hi,

the BIND extensions to Apache Jackrabbit
(<http://jackrabbit.apache.org/>) that I mentioned earlier are now
available in the svn trunk
(<http://svn.apache.org/viewvc/jackrabbit/trunk/>).

Implementation restrictions:

- Jackrabbit does not allow bind cycles, so none of the functionality
around status code 208 is implemented,

- In some cases, status 204 is returned instead of 200 (see discussion
below)

- Jackrabbit does not allow two bindings to the same node within the
same parent (will have to figure out why that is)

(thanks to Manfred Baedke for the implementation!)

BR, Julian


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>


Reply | Threaded
Open this post in threaded view
|

Re: BIND and HTTP status codes

Julian Reschke
In reply to this post by Julian Reschke

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