我正在使用的WebDAV库发出此请求

MKCOL /collection HTTP/1.1

由于/ collection存在，Apache向其发出301

HTTP/1.1 301
Location: /collection/

而不是

HTTP/1.1 405 Method Not Allowed

规范对此有些含糊(或者可能是我的阅读)，但是在发布MKCOL时，收藏名称应始终以斜杠结尾(因为它是收藏)？

解决方案

如我们所知，HTTP代码301的意思是"永久移动"。

Apache会慷慨地将我们重定向到正确的URL。它无法为我们提供405，因为我们提供的URL不存在任何资源。但是，它也不能使用该确切的URL创建资源。它所能做的就是使用正确的URL创建资源，然后将我们重定向。

但是要回答问题，我们应该以" /"结束集合，以消除歧义，否则最终的URI规范化行为取决于我认为的服务器。我不相信在任何RFC中都必须加上斜杠。

编辑：

MKCOL可能会成功而不使用斜杠，但是请注意，报告创建的资源具有斜杠。

根据RFC，服务器可以选择。因为它确定URL规范化过程，只要不违反规范即可。

然后，服务器可以尝试对我们在每次操作中发送的URL进行标准化，返回大量3xx代码。这变得昂贵。或者它可以在一开始纠正我们(POST，MKCOL等)，然后失败或者之后重定向。

但关键点在于，它将始终让我们知道其首选的URL。

RFC 2616上的HTTP URL方案

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

请注意，没有提及如何定义abs_path。同样，服务器也不能严格按照规范忽略斜线。因此，发出" MKCOL / collection"并创建没有新" / collection /" URL的常规2xx是不正确的。

AFAIK，定义abs_path的相关RFC未指定结尾斜杠。因此，服务器如何比较和标准化这些内容取决于服务器。