disallowing directories and files with the same name?

[michielbdejong]

we should either explicitly allow this or explicitly forbid this. i thought we were explicitly forbidding it, but i searched through the spec and couldn't find anything about this

[michielbdejong]

maybe trying to store '/foo' if '/foo/bar' exists, or trying to store '/foo/bar' if '/foo' exists, should result in a 409

[nilclass]

That would work, but it may clash with actual edit conflicts (i.e. when the provided version in the If-Match header of a PUT doesn't match the actual version on the server), so we either need to use different status codes for the two situations, or introduce some error format.

For example in case of a edit conflict the server could reply with status 409 and something like { "reason":"outdated","expected":"123","current":"234"} and in case of a directory vs. file conflict something like {"reason":"directory-exists"} (your first example) or {"reason":"file-exists"} (your second example).

That would work, but I think it would still be nicer to have different status codes. Not sure which one though. Shall we invent a new one?

[michielbdejong]

oh right, i forgot we're already using 409 for that. hm, it should definitely start with a 4, and then most mean something else. looking at https://en.wikipedia.org/wiki/List_of_HTTP_status_codes i think the short list would be:

405 Method Not Allowed
406 Not Acceptable
415 Unsupported Media Type
417 Expectation Failed
422 Unprocessable Entity
424 Method Failure

or we could indeed invent something like '419 Path Conflict' to distinguish it from versioning conflicts...

[nilclass]

I think 422 sounds pretty good ("The request was well-formed but was unable to be followed due to semantic errors."), though I don't know what the convention is on re-using status codes for slightly different purposes (WebDAV uses it for "semantically erroneous XML instructions").
"419 Path Conflict" also sounds nice. My all time favorite candidate still is "418 I'm a teapot" though.

[raucao]

I thought we said this is allowed. We asked once and it was decided it should work at the time.

[galfert]

I also remember that there was a discussion about this and it was decided that it should be possible to have a directory and a file with the same name.

Is there any specific reason you want to forbid this now?

[michielbdejong]

not a technical one, just minimizing wtf/min, mainly for server implementers, because of how file systems of many operating systems work.

it also makes it easier to implement for instance in the ownCloud server, but that is always only a secondary reason of course.

i think the main argument is "that's how linux works, so let's match that"

[raucao]

From my point of view it adds a WTF instead of removing one. Why should there be a special rule for any key? The key is the whole key including the slash. There is no file system.

[michielbdejong]

ok, so how about if we leave it out of scope? just say servers may do what the server implementer finds intuitive (so no need to pick a response code), but (for this reason) clients are not allowed to use it.

there is no situation i think in which this would be useful for a client. we can remark that clients may not rely on it (because it may not work on all servers), and make sure rs.js doesn't rely on it. no extra work for anybody, that way.

at least the current situation of the spec not mentioning it at all is not good.

[michielbdejong]

wait, that wouldn't work because the client may not know what is on there. not sure what to do here. let's brush this under the carpet until -02

[raucao]

et's brush this under the carpet until -02

Agreed.

[michielbdejong]

i propose saying the server 'MUST' return a 409 if a document clashes with a document, but 'MAY' return a 409 when foo is PUT while foo/ exists, or foo/bar is PUT while foo exists. that way, linux-fs-based servers don't have to go through extra effort to support it, and key-value-based servers don't have to go through any extra effort to check for it

[ghost]

So how do WebDAV, Google Drive and Dropbox deal with this? I suggest to follow their behavior...