我有一个处理文件来处理用户发送的数据，但在此之前，它会将来自客户端的输入与预期值进行比较，以确保客户端数据没有变化。
我可以说我对 HTTP 状态代码了解不多，但我对其进行了一些研究，并选择了哪一个最适合意外输入处理。所以我想出了：
400 Bad Request: The request cannot be fulfilled due to bad syntax
417 Expectation Failed: The server cannot meet the requirements of the Expect request-header field
现在，我不能真正确定要使用哪一个，我见过很多次使用 400 Bad Request，但是，我从解释中得到的是，错误是由于不存在的请求而不是非法输入造成的。
另一方面，417 Expectation Failed 似乎正适合我的用途，但是，我以前从未见过或试验过这种标题状态。
我需要您的经验和意见，非常感谢！
有关表单/流程页面草稿和我的实验的完整详细信息，请关注这个链接。
补充：我想要这个的另一个原因是防止 Google 操纵。这不仅会用在后端，还会用在前端，在前端将显示访客/用户交互并呈现页面内容。
我相信*，对于存在或允许存在的页面，给出 200 OK 或 403 Forbidden 状态代码是有效的。
*补充二：我现在已经研究了 417 和 100，发现它们与我尝试做的类似（至少仅适用于上传处理情况），在这里： http://benramsey.com/blog/2008/04/http-status-100-continue/
- IE：*链接到X站点的网页http://www.example.com/page.php?query=lol&query2=fail将会被 Google 编入索引，因为 HTTP 标头已正确给出。
我找到的解决方案：
确实，我可能又会遇到 404 错误。我只是想要一个不同的解决方案，如果 HTTP 提供了的话，但到目前为止，404 似乎仍然是最好的解决方案，谢谢大家，我的问题已经找到了答案。
答案1
如果 GET 请求的参数不正确，则规范的做法是返回 404（未找到）或 200（OK）。
RESTful 使用 GET 请求的方式是查询资源（获取某些内容）。因此，如果所需参数与现有资源不对应（因为它们不完整），则可以准确地说未找到 URI 中查询的资源。
实际上，如果您想避免浏览器忽略您的 404 页面并替换自己的页面（我正在查看 IE 9 和 10），您可能需要使用 200。如果您将应用程序视为资源，则 200 是合适的；您查询了应用程序，它返回了一个结果（这恰好是一个错误，但不是在 HTTP 级别）。但是，这种用法不是很 RESTful。
答案2
417仅当客户端发送了服务器无法满足的 HTTP 标头时才会发生此错误Expect，这与应用程序在请求中的“预期输入”没有任何关系。请勿使用它。
另一方面，400仅当 HTTP 请求中存在服务器无法理解的错误语法时才应发送错误。
虽然我认为这两种方法都不太适合应用程序逻辑中的验证失败，但我认为400它们更合适一些。
403我认为，您在 Stack Overflow 上的问题中考虑使用的错误是最好的选择。
当在 $_GET 中找不到预期值时，我只是使用了 403 Forbidden 标头，但是，仔细想想，这实际上并不是一个需要登录的操作（不是这个，当然用户必须首先登录才能查看管理面板），它更像是一个意外的值输入。
您正在考虑401，这是在需要身份验证时使用的响应代码。 403是对请求的一般拒绝，这听起来正是您想要的。
这一切都假设您想要返回一个4xx响应代码..这对于 API 来说很有意义..但对于面向用户的 HTML 页面，您更可能希望发送200包含正文中的错误信息。
答案3
我不太明白你在做什么，但是还有一个你可能没有考虑到的选项 - 200 - OK。原因是你正确收到了数据，问题是它对你的应用程序无效，这实际上不是 HTTP 协议的问题。
此处相关的 rfc 是rfc2616。您可以使用 400，但您需要向客户端提供修改数据的能力，来自 rfc
10.4.1 400 错误请求
由于语法错误，服务器无法理解请求。客户端不应在未做任何修改的情况下重复该请求。
关于 417，rfc 说
10.4.18 417 期望失败
该服务器无法满足 Expect 请求标头字段中给出的期望（参见第 14.20 节），或者，如果服务器是代理，则服务器有明确的证据表明下一跳服务器无法满足该请求。
因此如果您不使用预期标头，则可能不应该使用此响应。