Cyrus webdav with Joplin

Anatoli me at anatoli.ws
Sun Dec 1 13:57:57 EST 2019


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
> 


More information about the Info-cyrus mailing list