Trailing slash missing on CreateDirectory

[odrobnik]

We found that when uploading to an NGNIX Web server we would get "409 Conflict" errors... the reason was, that CreateDirectory does not append a trailing slash.

Ref WebDAV RFC:

"There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it should return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients should use the "/" form of collection names."

Apache WebDAV apparently deals with the missing trailing / by appending it, NGNIX doesn't.

So we suggest to always add the / as per the "standing convention" mentioned above.

[lookfirst]

👍 Want to submit a PR?

[odrobnik]

@lookfirst Sorry, but I am an iOS developer and don't know the least bit of Java.

[dkocher]

The URI parameter for creating directory resources in the library is of type String, therefore you can just always pass the URI with a / appended. I would leave this to the callers responsibility and not mess around with the parameter passed which would break backward compatibility.

[odrobnik]

@dkocher: not passing it with trailing slash is plain wrong and fails on NGNIX. There is no backwards compatibility that this COULD break if you only add a slash if it is missing.

WebDAV RFC states that collections have to be addressed with trailing slash. This is counter to how users are specifying folders when you e.g. Create them with mkdir - furthermore you get a counterintuitive error 409.

API should work such that it does not surprise a new user who is reasonably knowledgeable in UNIX matters. For these reasons sardine should do the right thing as suggested by the RFC

[dkocher]

@odrobnik I agree with you this is best practice and we do the same when referring to collections always appending a trailing slash. However the RFC you state says In general clients should use the "/" form of collection names. therefore we should still allow arbitrary URIs to be passed to the library and not mangle names. If required by RFC, it would say must.

[odrobnik]

I believe that SHOULD is strong enough to warrant the change, especially in light of NGNIX not accepting URIs without.

[dkocher]

I will leave this to @lookfirst to decide upon.

[lookfirst]

I agree with David. We need to allow both urls to be passed into sardine without mangling them under the covers.

On Apr 5, 2016, at 4:13 AM, David Kocher notifications@github.com wrote:

I will leave this to @lookfirst to decide upon.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[odrobnik]

@lookfirst A pity... maybe I have more luck with an issue for the NGNIX WebDAV module developers. Apache has a workaround in place.

I don't get why you "need to allow both urls to be passed"...

[lookfirst]

My brain is so full of other stuff right now, but here is my question:

http://www.foo.com/alskdjf could easily be a file or a directory.

If the client appends the '/', then wouldn't that break a file download?

[odrobnik]

@lookfirst I was only every talking about the parameter for CreateDIRECTORY which implies that it has to be a collection you are referencing by the UI. That's the only place where you DO know that it is not a file.

[lookfirst]

@odrobnik Why is it so hard for you to pass in a directory with a trailing slash? Even our documentation shows an example with a "/" at the end.

[odrobnik]

@lookfirst it's not hard. I only lost almost a day wondering why we would be getting a 409 Conflict error with NGNIX because nobody knows that. It was only by experimenting with curl and trying out multiple combinations and then searching for "slash" in the RFC that I learned about that.

So, if you are not making this change, then you should either note that in the documentation, or emit a warning. As NGNIX becomes more and more used as WebDAV you will get more and more people facing the same problem. A frustrating problem to have. Which you can easily prevent.