Fatal编程技术网
  • apache/
  • Apache mod_dav 400对不存在的集合资源的错误请求

Apache mod_dav 400对不存在的集合资源的错误请求

apache http

Apache mod_dav 400对不存在的集合资源的错误请求,apache,http,webdav,Apache,Http,Webdav,Apache似乎向一个简单的不存在的集合资源发回了一个400错误的请求 我有一个资源/test/junit/test.bin。我想检查集合/test/junit/test.bin/是否存在（即同名的集合）——根据RFC2518，集合（带斜杠）和非集合是不同的。当我在/test/junit/test.bin/上发出一个PROPFIND时，Apache响应一个400错误的请求 现在，我了解到许多人和实现已经模糊了集合和非集合之间的界限——也就是说，集合是否必须有一个结束斜杠。但不管是什么情况，集合/

Apache似乎向一个简单的不存在的集合资源发回了一个400错误的请求

我有一个资源
/test/junit/test.bin
。我想检查集合
/test/junit/test.bin/
是否存在（即同名的集合）——根据RFC2518，集合（带斜杠）和非集合是不同的。当我在
/test/junit/test.bin/
上发出一个
PROPFIND
时，Apache响应一个400错误的请求

现在，我了解到许多人和实现已经模糊了集合和非集合之间的界限——也就是说，集合是否必须有一个结束斜杠。但不管是什么情况，集合
/test/junit/test.bin/
都不存在——对不存在的集合发出
PROPFIND
不是“错误的请求”。Apache不应该简单地发布标准404 Not Found或410 Gone吗？我的请求有什么不好的地方

PROPFIND /test/junit/test.bin/ HTTP/1.1
depth: 1
content-length: 102
authorization: BASIC XXXXX
host: example.com

<?xml version="1.0" encoding="UTF-8"?>
<D:propfind xmlns:D="DAV:">
    <D:allprop />
</D:propfind>

HTTP/1.1 400 Bad Request
Date: Mon, 23 Jan 2012 15:30:37 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2 SVN/1.7.2 mod_jk/1.2.28
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
是的，我知道存在同名的资源，我正在询问集合的属性。所以我们可以说“这就是为什么Apache要这么做”。但这并不能解释任何事情——它只是对Apache将做什么的预测。我想知道为什么Apache认为退回400比退回404更合适？

以下是猜测：

Apache实际上允许将子路径发送到资源。PHP的一个示例：

http://example.org/index.php/foobar
Foo条将作为路径_信息发送到index.php。我的猜测是，正是这个功能现在错误地发回了HTTP/1.1400

一个合适的响应应该是404找不到，尽管因为它只是一个添加的斜杠，我个人可能只是映射/test.bin/到/test.bin

重定向到/test.bin也可以

你要知道我不是普通人，我90%的专业时间都花在HTTP和WebDAV、CalDAV等上。

我在Windows 2012上作为WebDAV服务器运行Apache 2.4时遇到了同样的错误，并解决了禁用“mod_negotiation.so”的问题：

我个人想知道apache是否在错误日志中显示了更多细节。您可以将错误日志级别设置得相当高。好主意——我已经从日志中添加了相关条目。这是关于你会猜到的。我不同意Apache的方法——还有人同意吗？我已经向Apache提交了一个bug：谢谢您的回复。我不太明白你说的是什么，当你说“Apache实际上将允许子路径发送到资源”时，当你说“Foo bar将作为路径信息发送到index.php”。RFC 2518特别提到PROPFIND方法时，允许使用“Depth”头指定应返回哪些子资源，并且非常具体地说明了应该如何解释它。我在RFC2518中找不到任何语言谈论路径信息，或者如果非集合资源具有类似的名称，则集合应被区别对待。至于您建议的将
/test.bin/
映射到
/test.bin
，这似乎完全不符合RFC2518。RFC说“…资源可以接受一个URI，但不带尾随“/”以指向集合。在这种情况下，它应该在响应中返回一个内容位置头，指向以“/”结尾的URI”，但它没有提供相反的映射（例如删除尾随斜杠），这正是本文讨论的内容。是的，我不是在说标准。这显然是apache错误地实现的。你问的是一个理由，为什么它可能被错误地执行，所以我给你我最好的赌注。你希望从中获得什么？ 
http://example.org/index.php/foobar

#LoadModule negotiation_module modules/mod_negotiation.so