When creating a collection via WebDAV should the name of the collection end with a slash

Question

A WebDAV library I'm using is issuing this request

MKCOL /collection HTTP/1.1

To which apache is issuing a 301 because /collection exists

HTTP/1.1 301
Location: /collection/

Rather than a

HTTP/1.1 405 Method Not Allowed

The spec is a bit vague on this (or it could be my reading of it), but when issuing an MKCOL, should the name of your collection always end with a slash (as it is a collection) ?

Answer 1

HTTP Code 301 means "Moved Permanently" as you know.

Apache is graciously redirecting you to the proper URL. It can't give you a 405 because no resource exists with the URL you provided. But it can't create the resource with that exact URL either. What it can do is create the resource with the proper URL then redirect you.

But to answer your question, you should end collections with "/" to remove ambiguity, otherwise the resulting URI normalization behavior is up to the server I believe. I don't believe adding that trailing slash is mandated by any RFC.

EDIT:

The MKCOL may succeed without the trailing slash, but notice that the resource reported created has a trailing slash.

The server has an option, according to the RFC. Since it determines the URL normalization procedure as long as it doesn't violate the spec.

The server then can either try to normalize ever URL you send it's way on every operation, returning lots of 3xx codes. This gets expensive. Or it can correct you in the beginning ( POST, MKCOL, etc. ) then fail or redirect after that.

But the key point is that it will always let you know the URL it prefers.

Something on HTTP URL Scheme from RFC 2616

3.2.3 URI Comparison

When comparing two URIs to decide if they match or not, a client
SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:

  - A port that is empty or not given is equivalent to the default
    port for that URI-reference;

    - Comparisons of host names MUST be case-insensitive;

    - Comparisons of scheme names MUST be case-insensitive;

    - An empty abs_path is equivalent to an abs_path of "/".

Characters other than those in the "reserved" and "unsafe" sets (see
RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

For example, the following three URIs are equivalent:

  http://abc.com:80/~smith/home.html
  http://ABC.com/%7Esmith/home.html
  http://ABC.com:/%7esmith/home.html

Notice no mention on how abs_path is defined. Also the server can't strictly speaking ignore your slash either according to the spec. So, issuing a "MKCOL /collection" and getting a regular 2xx created with no new "/collection/" URL is incorrect.

AFAIK, related RFCs that define abs_path do not specify the trailing slash. So it's up to the server on how it compares and normalizes those.