Question

在这个问题中，我在讨论HTTP请求方法。有关HTTP请求方法的详细说明，请参阅RFC 2616，尤其是第5.1.1节和第9节。

请求资源（URI，URL，网页）的常用方法是GET方法（如果只需要标题，则为HEAD）。

通常，仅当客户端发送到服务器的数据不应出现在URI中时，才使用POST方法。帐户名称和密码或其他敏感表单数据通常以这种方式传输。（当然，你仍然需要SSL，因为仅此一项不提供加密。）

我的大部分资源（URI）都不需要POST方法。例如，应该通过GET检索包含我的文章的页面。正确请求行的示例：

GET /myarticles HTTP/1.1
GET /copyrightnotice HTTP/1.1
GET /blog/2011/03/14/something.html HTTP/1.1

唯一需要POST的是登录页面（已输入表单的帐户和密码在POST正文中发送）和某些其他特殊页面。例子：

POST /performlogin HTTP/1.1
POST /formtarget HTTP/1.1
POST /savevote HTTP/1.1

我的问题是，我是否应该在不需要它的页面上禁用POST方法（例如/ myarticles，/ copyrightnotice等）？

换句话说，如果我收到此请求行：

POST /blog/2011/03/14/something.html HTTP/1.1

我应该

a）发回405（不允许的方法）错误代码以及Allow：标题，如下所示：

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Date: ...

b） - 或者 - 我应该简单地将POST请求视为GET请求吗？

HTTP/1.1 200 OK
Date: ...

HTML-content-here

重要，还是完全取决于我？使用选项b）时是否有任何警告/安全风险？我试图保持尽可能多的标准。

Answer 1

根本不重要。有一个（非常小的）论点，它可能会使您的网站不太容易限制允许的请求方法，但不是真正意义上的。您唯一需要注意的是限制（并且可能完全不允许）使用PUT和DELETE，因为它们将直接更改您的服务器的文件系统。

如果POST请求被收到预期获得GET的页面，那么有可能是有人在玩，看看您的网站会接受什么，可能会尝试找到安全漏洞。话虽如此，也不可能有任何潜在的漏洞也无法被GET请求利用。

如果您不小心将method="post"放在<form>上并不是您的意思，那么同时允许这两者可能会很有用，但如果您这样做，它可能会同时使用{{1}}更难找到进一步显示的问题。如果您的脚本可以处理来自您网站上多个表单的表单提交，那么接受这两个表单可能是一个想法，但对于普通页面，应该没有必要。

您在问题中忘记提及的一件事（不是重要）是在通过HTML表单上传文件时也需要POST请求 - POST请求的重点不仅仅是隐藏URL中的数据（虽然这是一个有用的副作用），但允许客户端将对象发送到服务器。这个对象可以是表单数据，也可以是文件，XML文档等等。例如，许多XML-HTTP API使用POST（因此他们应该 - 我遇到了过去使用过GET的那个，而且它是一个噩梦，因为它意味着你不能在文档中有任何空格，或者它打破了请求，你必须对XML文档进行urlencode，这是时间/资源消耗和无意义的。）

确实可以自行决定。

Answer 2

一个。

虽然我怀疑它很重要，但b不会造成伤害。如果要创建RESTful Web服务以使其行为一致，那么您应该对此严格要求。如果你正在创建一个网站，有人怎么会意外地发布帖子？

正如你所知，整个句子开始通常，POST方法仅在...... 错误时使用。

这绝对不是POST的重点，并且显示出对HTTP的潜在误解。根据协议，GET和POST是非常不同的。一个应该除了检索数据之外什么都不做，另一个应该导致正在采取的行动。

事实是，在网页和网络服务器的历史中，这些规则经常被忽略，并且最近才开始流行使用RESTful Web API设计。

Answer 3

重要的一个原因是协议规范假设GET请求所服务的内容是幂等的，而POST服务的东西则不是。例如，对于正在执行HTTP / 1.1请求流水线操作的客户端而言，这很重要，并且使用动词作为提示，代理可能会有不同的行为。

我们距离上述规则100％占用时间的世界还有很长的路要走，但我鼓励您尽自己的责任 - 在您只是检索文档的情况下使用GET，在修改资源，更改状态等时使用POST

哦，顺便说一句，发送查询字符串和POST请求并非闻所未闻。市场上有很多主要应用程序。

我应该接受所有资源的POST方法吗？

3 个答案: