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
