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@xxxxxxxxxx> 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 ---- 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
