为啥访问网站显示这个 Bad Request是啥意思啊

Posted 2023-05-11

1.如果确定域名已经解析生效，但是仍然不能访问，出现Bad Request (Invalid Hostname).那么这就可能是您没有绑定该域名的原因 2.也有一部分情况， 比如一部分程序你上传之后就是用服务商提供的三级域名访问也是那个样子。也会有Bad Request (Invalid Hostname的错误提示 3.也许是限制了访问线程。也就是说当同时访问该网页超过一定人数的时候，其它人浏览时就会出现你所说的情况 来自百度 http://zhidao.baidu.com/question/62984251.html?fr=ala0 查看原帖>> 参考技术A

一般来说与你电脑无关，错误请求（无效主机名） 域名已绑定主机，但主机未绑定域名，就会出现这种情况。

总结页面出现Bad Request (Invalid Hostname)的原因： 

如果确定域名已经解析生效，但是仍然不能访问，出现Bad Request (Invalid Hostname)，那么这就可能是您没有绑定该域名的原因。

也有一部分情况， 比如一部分程序你上传之后就是用服务商提供的三级域名，访问也是那个样子。也会有Bad Request (Invalid Hostname的错误提示。

也许是限制了访问线程。也就是说当同时访问该网页超过一定人数的时候，其它人浏览时就会出现你所说的情况。

400 BAD request HTTP错误码是啥意思？

【中文标题】400 BAD request HTTP错误码是啥意思？

【英文标题】：400 BAD request HTTP error code meaning?400 BAD request HTTP错误码是什么意思？

【发布时间】：2013-11-09 09:08:45

【问题描述】：

我有一个 JSON 请求，我将其发布到 HTTP URL。

是否应该将其视为400，其中存在requestedResource 字段但"Roman" 是该字段的无效值？

[requestedResource:"Roman"] 

这是否应该被视为400，而"blah" 字段根本不存在？

[blah:"Roman"]

【问题讨论】：

也许402，如果他们真的想能够发送价值Roman，他们只需要多付钱给你:)

我看到的真实场景 - 我做了一个 PUT 调用来添加一些数据。我使用相同的请求正文再次进行了 put 调用并得到了 400，它告诉我之前的请求已经在处理中。我们的系统需要一些时间来添加这些数据是正常的。

我肯定最受关注，但要明确提及 - 这些请求应该是 400 个响应，因为它们不是有效的 JSON（不是我知道的问题的重点！） JSON 需要在 Property 周围加上引号名称，并且不像不需要引号的 javascript 对象表示法那样宽容。我对主要问题的回答如下。

【参考方案1】：

这让我想起了与其他人的常见对话，“我明白 - 我只是不同意”

400 表示服务器不理解

200 表示服务器准确理解并完全处理了请求。

当服务器返回 200 时，它表示“我理解您的要求，我处理它没有意外错误，这是我的正确响应”

200 表示您可以信任响应中发送的答案。也许答案是“不允许罗马人” - 但它仍然是一个正确的答案，生成时没有任何意外问题。

200 不表达有关预期错误或已处理异常的任何信息 - 因为这不是消息传输过程的一部分。这些是关于 HTTP 的状态代码，即传输本身的状态。

我认为应该避免模糊“传输/通信”与“处理”之间的界限。

对于那些更喜欢 HTTP 代码来指示处理中的问题（“我不同意”部分）的人来说，似乎 409 Conflict 最适用于“不允许罗马人”RFC 7231 409 Conflict

冲突几乎意味着“缺乏协议”，对吧？

无论您为 HTTP 响应代码选择什么，似乎每个人都同意您的响应应该解释为什么它失败，以及如何解决它。在 Roman 的情况下，也许会返回该字段的可接受值列表？

【参考方案2】：

400 表示请求格式不正确。也就是说，客户端发给服务端的数据流不符合规则。

在带有 JSON 有效负载的 REST API 的情况下，根据服务的 API 规范，400 通常（我会说正确）用于指示 JSON 在某种程度上是无效的。

按照这个逻辑，你提供的两个场景都应该是400s。

想象一下，这是 XML 而不是 JSON。在这两种情况下，XML 都不会通过模式验证——要么是因为未定义的元素，要么是因为不正确的元素值。那将是一个糟糕的要求。同样的交易。

【讨论】：

我同意你的观点，“按照这个逻辑，你提供的两个场景都应该是 400 的。”我认为 JSON 的内容在这里并不重要。当您说格式错误时，我想相信它以您发送的数据格式解决了问题，例如，如果您跳过 JSON 中的一个字段，您应该得到 400。

restapitutorial.com/httpstatuscodes.html 上有一组不错的 REST 响应代码。它还可能取决于您希望如何处理有效请求，例如 406（不可接受）或不允许的 405 方法。但是，400 是合适的，因为“由于语法格式错误，服务器无法理解请求。客户端不应该在没有修改的情况下重复请求。”

So "由于语法错误，服务器无法理解请求" 可以是 request 之一（例如， HTTP 标头格式错误）或请求携带的 数据（例如，缺少 JSON 值）？

Vidya 说“XML 永远不会通过模式验证”。要点是 XML 解析器区分格式良好（即语法上合理）和有效（即语义上合理，例如根据模式）的文档。 400 代码的描述是“由于 syntax 格式错误，服务器无法理解请求” - 所以它不应该用于验证错误，恕我直言。

@Vidya ***.com/questions/42851301/… 看看这个错误我也面临与这个错误类似的问题，如果你知道请帮助我

【参考方案3】：

作为补充，对于那些可能遇到与我相同问题的人，我使用$.ajax 将表单数据发布到服务器，并且我最初也遇到了400 错误。

假设我有一个 javascript 变量，

var formData = 
    "name":"Gearon",
    "hobby":"Be different"
    ; 

不要直接使用变量formData作为键data的值，如下所示：

$.ajax(
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: formData,
    success: function(data, textStatus)
        alert("Data: " + data + "\nStatus: " + status); 
    
);

改为使用 JSON.stringify 封装formData，如下所示：

$.ajax(
    type: "post",
    dataType: "json",
    url: "http://localhost/user/add",
    contentType: "application/json",
    data: JSON.stringify(formData),
    success: function(data, textStatus)
        alert("Data: " + data + "\nStatus: " + status); 
    
);

无论如何，正如其他人所说明的那样，错误是因为服务器无法识别请求导致语法错误，我只是在实践中提出一个实例。希望对某人有所帮助。

【讨论】：

我认为 OP 是在询问 400 是否是 return 的适当错误代码，当请求没有格式错误但不知何故不满足应用程序级要求时。例如。您可以创建一个在线计算器，将方程式作为 JSON 发送。如果您发送添加数字和字符串的有效 json，则请求是正确的，但对应用程序而言语义不正确。但是，您的浏览器会将请求视为“错误”。

【参考方案4】：

首先检查可能是错误的URL，如果正确则检查您发送的请求正文，可能的原因是您发送的请求缺少正确的语法。

详细说明，检查请求字符串中的特殊字符。如果使用的是（特殊字符），则这是此错误的根本原因。

尝试复制请求并分析每个标签数据。

【讨论】：

我收到 http 400 错误，我检查了我的请求有一些特殊字符。为了解决这个问题，我在内容类型中传递了 charset=UTF-8。

【参考方案5】：

选择 HTTP 响应代码是一项非常简单的任务，可以通过简单的规则来描述。唯一经常被遗忘的棘手部分是 RFC 7231 的第 6.5 段：

除了响应 HEAD 请求时，服务器应该发送一个 包含错误情况说明的表示， 以及它是暂时的还是永久性的。

规则如下：

如果请求成功，则返回 2xx 代码（3xx 用于重定向）。如果服务器出现内部逻辑错误，则返回 5xx。如果客户端请求有问题，则返回 4xx 代码。 查看所选类别中的可用响应代码。如果其中一个的名称与您的情况非常匹配，则可以使用它。否则只需回退到 x00 代码（200、400、500）。如果您有疑问，请回退到 x00 代码。 在响应正文中返回错误描述。对于 4xx 代码，它必须包含足够的信息，以便客户端开发人员了解原因并修复客户端。出于安全原因，5xx 不得透露任何细节。 如果客户端需要区分不同的错误并根据它有不同的反应，请定义机器可读和可扩展的错误格式，并在您的 API 中随处使用。最好从一开始就做到这一点。 请记住，客户端开发人员可能会做一些奇怪的事情并尝试解析您返回的字符串作为人类可读的描述。通过更改字符串，您将破坏这些写得很糟糕的客户端。因此，请始终提供机器可读的描述，并尽量避免以文本形式报告其他信息。

所以在你的情况下，如果从用户输入中获得“罗马”并且客户端必须有特定的反应，我会返回 400 错误和类似的内容：

    "error_type" : "unsupported_resource",
    "error_description" : "\"Roman\" is not supported"

或更一般的错误，如果这种情况是客户端中的错误逻辑错误并且不是预期的，除非开发人员犯了错误：

    "error_type" : "malformed_json",
    "error_description" : "\"Roman\" is not supported for \"requestedResource\" field"

【参考方案6】：

将400 状态码用于表明请求格式错误之外的任何其他目的都是完全错误的。

如果请求负载包含无法解析为 application/json 的字节序列（如果服务器需要该数据格式），则相应的状态代码为 415：

服务器拒绝为请求提供服务，因为 请求的格式不受请求的资源支持 请求的方法。

如果请求负载在语法上正确但在语义上不正确，则可以使用非标准的422响应码，或者标准的403状态码：

服务器理解请求，但拒绝执行。 授权将无济于事，并且不应重复请求。

【讨论】：

不，415 用于当实体被声称为错误类型时，例如image/gif 而不是Content-Type: 标头中的text/json。 - 如果多部分的组件指定了错误的类型，这可能也适用，请参阅tools.ietf.org/html/rfc4918 其中讨论 422 以进行更多讨论，

【参考方案7】：

在这两种情况下都不会出现“语法格式错误”。这是错误的语义。因此，恕我直言，400 是不合适的。相反，返回 200 以及某种错误对象（例如 "error": "message": "Unknown request keyword" 或其他）是合适的。

考虑客户端处理路径。语法错误（例如无效的 JSON）是程序逻辑中的错误，换句话说，是某种错误，应该以类似于 403 的方式进行相应处理，例如；换句话说，有什么不好的地方出了问题。

另一方面，参数值中的错误是语义错误，可能是由于用户输入验证不佳。这不是 HTTP 错误（尽管我想它可能是 422）。处理路径会有所不同。

例如，在 jQuery 中，我宁愿不必编写单个错误处理程序来处理诸如 500 之类的事情和一些特定于应用程序的语义错误。其他框架（例如 Ember）也将 HTTP 错误（如 400 和 500）视为大故障，要求程序员检测正在发生的事情并根据它是否是“真正的”错误进行分支。

【讨论】：

+1，HTTP中的P代表Protocol，如果响应是HTTP错误，应该是低级问题。多年来，我使用 torazaburo 描述的方法避免了很多代码复杂性。如果我们都编写 弹性 代码而不是频繁地因 HTTP 错误而崩溃，那么 REST 领域的痛苦就会减少。

200 表示请求已被处理，因此应该在客户端执行正常的成功逻辑。这里我们肯定有错误，所以响应不能有 2xx 或 3xx 代码。它也不能是 5xx，因为这是服务器端错误，我们在客户端有错误。所以那一定是4xx错误。但是响应正文中的错误描述是正确的做法，实际上是 HTTP 规范建议的一种方式。

422 更好，用于记录器、代理和其他工具

【参考方案8】：

想想期望。

作为客户端应用程序，您希望知道服务器端是否出现问题。如果服务器需要在blah 缺失或requestedResource 值不正确时引发错误，则适合使用 400 错误。

【参考方案9】：

来自w3.org

10.4.1 400 错误请求

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

【讨论】：

返回错误 400 的正确性不是基于字段与值，而是基于整个请求。我认为 HTTP 400 是一个不错的选择

您的意思是使用 400 响应来告诉客户端请求中的任何内容（即 url、标头、正文等）都可能是错误的，而不仅仅是正文？

对于 url，正确的代码是 404，对于标题，我想这是一个折腾，如果标题拒绝身份，403（禁止）似乎是正确的方法，但是如果标题正在确定呢输出格式？关于我认为适合 400 的唯一路径是在请求的操作没有意义且不应重复的情况下。我在 4 年前写了这个答案，这些天我觉得即使是错误也应该返回 200，并且错误应该只适用于 http 传输而不是有效负载。

这个答案涵盖了很多，虽然我还没有阅读所有图表***.com/a/34324179/16959

@JasonSperske 负载均衡器、代理和其他中间件经常使用状态码来帮助路由、报告和修复。幸运的是，像“422”这样的代码是明确与有效载荷有关的，因此规范中有一些空间用于有效载荷状态代码。