哪个 HTTP 状态代码用于未提供的必需参数？答案

【问题标题】：Which HTTP status code to use for required parameters not provided?哪个 HTTP 状态代码用于未提供的必需参数？
【发布时间】：2023-03-21 13:35:01
【问题描述】：

我有几个设计为使用 AJAX 调用的页面 - 如果它们无法显示，我会让它们返回异常状态代码，并且我的 javascript 将相应地显示一个错误框。

例如，如果用户未通过身份验证或他们的会话已超时并且他们尝试调用 AJAX 页面之一，它将返回 401 Unathorized。

如果服务器端发生真正奇怪的事情，我也有一些回报500 Internal Server Error。

如果在没有必需参数的情况下调用这些页面之一，我应该返回什么状态代码？（因此无法返回任何内容）。

我查看了wikipedia article on HTTP status codes，但我能找到的最接近我正在寻找的代码的是：

422 无法处理的实体
该请求格式正确，但由于语义错误而无法执行。

编辑：上面的代码是特定于 WebDAV 的，因此在这种情况下不太合适

谁能想到一个合适的代码返回？

【问题讨论】：

也可以看看（如果不是重复的话）：HTTP status code for bad data
@JulianReschke 我认为 4918 可以处理一些勘误表，首先要指定它确实更新了 2616，其次要澄清新的 HTTP 状态代码并非都是特定于 WebDAV 的。
@Alnitak：（1）它不会更新 RFC 2616，因为它没有必要。有一个状态码注册表，这就是正在使用的：greenbytes.de/tech/webdav/rfc4918.html#rfc.section.21.4> (2) 一般来说，HTTP 状态码应该是通用的；这就是为什么有一个注册表。
Duplicate。争论激烈...

标签： http http-status-codes

【解决方案1】：

如果在没有必需参数的情况下调用这些页面之一，我应该返回什么状态代码？（因此无法返回任何内容）。

你可以选择404 Not Found:

服务器没有找到任何匹配 Request-URI [假设您需要的参数是 URI 的一部分，即$_GET]。没有说明这种情况是暂时的还是永久性的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用并且没有转发地址，则应该使用 410 (Gone) 状态代码。当服务器不希望确切地显示请求被拒绝的原因或没有其他响应适用时，通常使用此状态代码。

（由我突出显示）

404 Not Found 是400 Bad Request 的子集，也可以采用它，因为它非常清楚这是什么：

由于语法错误，服务器无法理解该请求。客户端不应该不加修改地重复请求。

我实际上不能建议您选择使用超文本的 HTTP 客户端不存在的 WEBDAV 响应代码，但是您可以，这是完全有效的，您是服务器编码器，您实际上可以获取任何 HTTP 响应状态代码您认为适合您的 HTTP 客户端，而您也是该客户端的设计者：

11.2。 422 无法处理的实体

422 (Unprocessable Entity) 状态码表示服务器理解请求实体的内容类型（因此 415（不支持的媒体类型）状态码不合适），并且请求实体的语法是正确的（因此是 400 (Bad Request) 状态码不合适）但无法处理包含的指示。例如，如果 XML 请求正文包含格式正确（即语法正确），但是语义错误的 XML 指令。

IIRC 请求实体是请求主体。因此，如果您使用请求主体进行操作，则可能像 Julian 所写的那样合适。

你评论了：

恕我直言，400 的文本提到了格式错误的语法。我假设这里的语法与客户端发送到服务器的 HTTP 字符串的语法有关。

可能是，但它可以是任何语法表达的东西，整个请求，只有一些请求标头，或者特定的请求标头，请求 URI 等。 400 不是专门关于“HTTP字符串语法”，它实际上是对客户端错误的一般回答：

4xx 类状态代码适用于客户端似乎出错的情况。除了响应 HEAD 请求时，服务器应该包含一个实体，其中包含对错误情况的解释，以及它是暂时的还是永久的情况。这些状态码适用于任何请求方法。用户代理应该向用户显示任何包含的实体。

重要的部分在这里，您必须告诉客户出了什么问题。状态码只是说明出了问题（在 4xx 类中），但 HTTP 并未专门设计为使缺少的查询信息部分参数作为错误条件引起注意。事实上，URI 只知道有一个 query-info 部分，而不知道它的含义。

如果您认为 400 过于宽泛，如果问题与 URI 相关，我建议您选择 404，例如$_GET 变量。

【讨论】：

恕我直言，400 的文本提到了格式错误的 syntax。我假设这里的语法与客户端发送到服务器的 HTTP 字符串的语法有关。在缺少参数的情况下，语法仍然是正确的，这让我相信 400 是一个糟糕的选择。如果我在任何地方错了，请纠正我:)
@Thrustmaster：你没看错，只是心胸狭窄。只是因为它可能是那个，并不意味着它不能意味着另一个。特别是对于正确的 x00 代码。添加了更多信息。
我可能有点狭隘，呵呵。我还是不相信。我想我会在进一步评论之前完整阅读 RFC。感谢您的回答，赞成:)
是的，阅读 RFC。大概放轻松一点吧；）最重要的是你有一个4xx的代码，万一客户不明白，它会把它当作400。因此，最好从400 和您附加的有用实体（响应正文）开始，如果您得出更好的结论，请选择更具体的代码。最重要的部分是您告诉用户他/她做错了什么，以便将来请求预期操作时可以达到 2xx 请求状态。

【解决方案2】：

我不知道 RFC 编写者的意图，但我看到在这种情况下使用的状态代码是 400 Bad Request。

【讨论】：

400 是，IMO，一个糟糕的选择。在 hakre 的答案下方查看我的评论。如果我有任何错误，请告诉我:)
我做到了（可能不在评论中），404 :)
有时我想知道标准的http状态码是否足够。

【解决方案3】：

422 是一个常规的 HTTP 状态码；它在 WebDAV 之外使用。与其他人所说的相反，这没有问题； HTTP 有一个状态码注册表是有原因的。

见http://www.iana.org/assignments/http-status-codes

【讨论】：

当然你也可以使用 478，这是你的选择，你不受任何 RFC 的约束。但是，我不建议为这个问题重新使用 WEBDAV 特定代码。从技术上讲，您也不需要依赖 IANA，只要它是 4xx，任何 HTTP 用户代理都可以清楚地看到，请参阅 HTTP 规范。这只是一个你想要什么的问题。
嗯，422 是 IANA 状态代码注册表中的代码，在 IETF 标准跟踪 RFC 中定义。 478 不是。
那又怎样？使用 478 需要数年时间，如果是这种情况，并且您已经围绕它建立了公共资源，IETF 将反映它。尤其是如果客户端是您自己控制的 AJAX 客户端，则在您的域之外没有太多需要关心的问题。使用未使用的状态代码可能比重新使用 IANA 已经声明它用于特定目的的东西（WEBDAV 连接）更明智。
使用当前未分配的代码是个坏主意。有人可能会用不同的语义来指定它，有一天你会发现 HTTP 库为它添加了特殊处理。所以不要。不，IANA 没有声明 422 是特定于 WebDAV 的。所有注册表页面都说是定义状态代码的位置。我在这里完成了；如果您对此不信任，我建议您在 IETF HTTP 邮件列表中询问。

【解决方案4】：

引用 400 的描述

由于语法错误，服务器无法理解该请求。客户端不应该在没有修改的情况下重复请求。

（强调我的）

这是格式错误的语法，当浏览器向服务器发送请求时，情况并非如此。它只是缺少参数的情况（虽然没有格式错误的语法）。

我建议坚持使用 404 :)

（如果我在任何地方错了，请专家纠正我:)）

【讨论】：

见trac.tools.ietf.org/wg/httpbis/trac/ticket/303; RFC 2616 的修订版将阐明“格式错误的语法”只是众多潜在原因之一。

【解决方案5】：

仔细阅读：

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

422 是特定于 WebDAV 的东西，我还没有看到它用于其他任何用途。

400，尽管不是为了这个特定目的，但似乎是一个常见的选择。

如果您的 API 是 RESTful 或类似的（使用 URI 的路径部分来指示搜索参数），404 也是一个可行的选择

【讨论】：

422 不是特定于 WebDAV，它用于其他上下文。