MKCOL refuses creation without trailing slash

[chrysn]

Some WebDAV clients that create collections do that without including the trailing slash. The logs offer no further explanation, and to a casual user the 409 error is confusing (as it indicates that the parent collection is absent).

RFC4918 recommends them to have a trailing slash, but given that several applications don't send a trailing slash, it stands to reason that it's common for servers to accept it. Section 5.2 even gives concrete guidance that in such a case, the server should accept and send a Content-Location header ("There is a standing convention").

Example clients that don't are webdav-js (​https://github.com/dom111/webdav-js) and Stratospherix FileBrowser for Business; some examples are around for other clients that employ workarounds (eg. ​https://github.com/laurent22/joplin/issues/523).

[Maxim Dounin]

This was previously discussed in #604 (mostly in Russian, unfortunately).

​Section 5.2 says:

   There is a standing convention that when a collection is referred to
   by its name without a trailing slash, the server MAY handle the
   request as if the trailing slash were present. 

That is, the server MAY handle it as if the trailing slash were present. It is, however, not required to. And this is not what nginx normally does: for example, for normal GET requests it used to return a redirect instead. That is, clearly nginx does not follow this convention.

Clients not using trailing "/", in contrast, are violating the SHOULD clause in the same paragraph:

   In general, clients SHOULD use the trailing slash form of
   collection names.  If clients do not use the trailing slash form the
   client needs to be prepared to see a redirect response.

It is believed that returning a redirect to MKCOL requests without a trailing "/" might not be a good idea, hence the error is returned. We can consider, however, returning a redirect instead if the affected clients are known to handle redirects.

If you think that 409 is confusing here, feel free to suggest a better code. I don't think there is one which fits significantly better though.

[chrysn]

If nginx wants to be strict here I'm perfectly fine with it and appreciate it. Then I can refer problematic client implementations to the SHOULD and tell them that there *are* widespread servers out there that insist.

For error codes, I'd suggest 405 on MKCOL-without-slash (as PUT would be acceptable where MKCOL isn't), and 404 for DELETE-without-slash on a collection (as a resource with that precise name does not exist).

Either way, I'm no expert in those methods and the suitable codes can be discussed a lot and still not help users. It would help if a clarifying text like "Path does not describe a collection" would be shown somewhere in those two cases, but it appears to me that neither the log format (which only logs codes) nor the error pages (which are generated solely on the code) is a viable candidate there.

[Maxim Dounin]

Ok, thanks for your feedback. The clarifying text is available in the error log, and can be seen by the server administrator.

404 looks completely wrong to me, as certainly there is a resource available with the name requested - the one which returns a redirect. 405 might be indeed a better option, though I don't think it worth the change.

Either way, the only real solution is to fix clients which break the SHOULD.

Closing this as a duplicate of #604.