Cyrus webdav with Joplin

Mon Dec 2 23:05:35 EST 2019

The meth_mkcol function (and others in http_dav.c?) probably should be
checked thoroughly, it looks like inside some conditions it would be
better to use different status codes.

I'm forwarding this mail to cyrus-devel@ and CC'ing Ken who probably
knows this part better than anyone.

WebDAV is an HTTP extension so it is guided by the HTTP standard RFC
7231 (HTTP/1.1) with additions by its own standard RFC 4918 (WebDAV) and
then MKCOL is further extended by RFC 5689 (Extended MKCOL).

For me it seems that in some aspects the later two contradict the first one.

>From RFC 7231 (HTTP/1.1 [1]): The 403 (Forbidden) status code indicates
that the server understood the request but refuses to *authorize* it.

>From RFC 4918 (WebDAV [2]): 403 (Forbidden) - This indicates at least
one of two conditions: 1) the server does not allow the creation of
collections at the given location in its URL namespace, or 2) the parent
collection of the Request-URI exists but cannot accept members.

The second condition is what could be used here (the target URL can't
accept the specified member which is the current behavior of Cyrus), but
it has nothing to do with authorization as defined by HTTP/1.1 for 403.

RFC 7231 (HTTP/1.1 [3]): The 405 (Method Not Allowed) status code
indicates that the method received in the request-line is known by the
origin server but *not supported by the target resource* ([2]), which in
this case would mean that the URI on which MKCOL is tried does not allow
MKCOL method at all, which is not true.

>From RFC 4918 (WebDAV [2]): 405 (Method Not Allowed) - MKCOL can only be
executed on an unmapped URL. ???

RFC 7231 (HTTP/1.1 [4]): The 409 (Conflict) status code indicates that
the request could not be completed due to a *conflict with the current
state of the target resource*, which in this case is the URI on which
MKCOL is tried and this is exactly the case: the path already contains a
collection so "the request could not be completed due to a conflict with
the current state of the target resource".

>From RFC 4918 (WebDAV [2]): 409 (Conflict) - A collection cannot be made
at the Request-URI until one or more intermediate collections have been
created. The server MUST NOT create those intermediate collections
automatically.

Additionally, RFC 7231 (HTTP/1.1 [5]): The 404 (Not Found) status code
indicates that the origin server *did not find a current representation
for the target resource*, which IMO is the case when a/b is not found
when a/b/c creation is requested, but the WebDAV RFC says it's 409
Conflict, go figure.

BTW, citing the HTTP/1.1 RFC: The origin server MUST generate an Allow
header field in a 405 response containing a list of the target
resource's currently supported methods [3].

[1] https://tools.ietf.org/html/rfc7231#section-6.5.3
[2] https://tools.ietf.org/html/rfc4918#section-9.3.1
[3] https://tools.ietf.org/html/rfc7231#section-6.5.5
[4] https://tools.ietf.org/html/rfc7231#section-6.5.8
[5] https://tools.ietf.org/html/rfc7231#section-6.5.4

On 2/12/19 07:13, Johan Hattne wrote:
> Hi Anatoli;
> 
> Thanks for your reply; I’ll be focusing on the MKCOL for now:
> 
> I don’t know about permission to overwrite quite yet, but from looking at the source it seems the break (at https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/http_dav.c#L5590) is what causes HTTP_FORBIDDEN to be returned.  Now looking at the code in the client (https://github.com/laurent22/joplin/blob/master/ReactNativeClient/lib/file-api-driver-webdav.js#L164) it appears Joplin is expecting 405, or possibly 409, given the explanation in the comment following line 164.
> 
> Given all that, it would seem to me that Cyrus should possibly change the aforementioned break to a return HTTP_CONFLICT, or HTTP_NOT_ALLOWED if the comment in Joplin is correct.  I haven’t tested this yet (nor have read the RFC:s thoroughly), but I’d be happy to submit a pull request if this all checks out.  Opinions?
> 
> // Best wishes; Johan
> 
>> On Dec 1, 2019, at 10:57, Anatoli <me at anatoli.ws> wrote:
>>
>> Hi Johan,
>>
>> In RFC 7231 (HTTP 1.1) section 3.1.1.5
>> (https://tools.ietf.org/html/rfc7231#section-3.1.1.5) it says that CT
>> header SHOULD be present, otherwise the recipient may interpret it the
>> way it wants, so IMO no problem on the Cyrus side here. For
>> application/json for example it MUST be present, application/xml doesn't
>> demand that, but not sending it IMO is not a good behavior for
>> interoperability.
>>
>> For collection that exists, does the user that makes the request have
>> the rights to overwrite the collection? If not, 403 is the correct SC
>> (status code). 405 should be used when the specified method is not
>> allowed at all on the specified path, independently of the current
>> server state, which is not the case here.
>>
>> So, again IMO no problem on the Cyrus side here, but if the user has
>> sufficient rights, instead of 403 I'd use "409 Conflict" which is the
>> recommended SC when a record with specified ID/name already exists.
>>
>> Regards,
>> Anatoli
>>
>> On 28/11/19 04:40, Johan Hattne wrote:
>>> Dear all;
>>>
>>> I’m trying to get Joplin (https://joplinapp.org) to work with Cyrus’s webdav module, and I’ve run into two issues:
>>>
>>> (1) When attempting to MKCOL a collection that already exists, Cyrus is responding with a 403, rather than a 405, which is what Joplin expects.
>>>
>>> (2) Cyrus returns an error if the Content-type isn’t set where additional XML-formatted information is required in a POST to complete a request.
>>>
>>> My skimming of the relevant RFC:s now lead me to believe that Cyrus is right on both counts; however, I don’t know enough about this to say for sure.  Can anyone here confirm, or are these genuine Cyrus bugs?
>>>
>>> // Best wishes; Johan
>>> ----
>>> Cyrus Home Page: http://www.cyrusimap.org/
>>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>>> To Unsubscribe:
>>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
>>>
>> ----
>> Cyrus Home Page: http://www.cyrusimap.org/
>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
>> To Unsubscribe:
>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
> 