3

当我将一些参数放入 URL 时，有时我会收到一个错误，因为应该是“400 OK”的有效请求。

相同的 URL 和参数将在 99% 的情况下有效，但我看到我们的日志中出现错误。

这是由于某些因素而可能发生的晦涩难懂的事情，还是我的应用程序特有的事情导致了奇怪的标题混搭？如果前者没有答案，我猜是后者:)

更新

对于评论，“它”是一个相对简单的 RESTful API 编写的。现在它几乎总是返回正确的标题，如 400 和错误正文或 200 和 ok 正文。当错误的标头到达 Web 客户端时，Web 客户端会使用它收到的消息 ping 报告 URL，以便我们可以区分我们的 Web 应用程序和移动应用程序之间的 API 错误。据我们所知，没有任何代码组合可以使这个“400 OK”成为地狱。但鉴于在我们的代码混乱之外似乎不可能发生这种情况，我将进行更深入的研究。

更新 2

好的，我对我们的框架进行了比以往更深入的研究，并与一些开发人员进行了交谈。

它通过对 API 的 AJAX 调用将信息返回给浏览器。

浏览器检测到“400 OK”并将其发送回我们的服务器，在那里我们得到了这个奇怪的报告。没有人亲眼看到这种情况发生，但日志说它正在发生。

在我们的代码库中实际上有零代码会返回 400 OK，因为我们的 HTTP 标头处理程序中只有 400 是“400 bad request”

我现在想知道是否有一些我偶然发现的浏览器/jquery/ajax 错误。

UPDATE 3（因为你不能有太多的信息）

我检查了浏览器如何看到问题所在。jQuery $.ajax 报告的失败会触发回调。然后我们有这样的代码：

xhr.always(function() {
  var request = [ this.type, this.url, this.data ].join(' '),
      response = [ xhr.status, xhr.statusText, xhr.responseText ].join(' ');

  $.ajax({ 
    url   : REPORTING_URL,
    type  : 'POST', 
    data : { request : request, response : response }
  });
});

我们知道这“大部分”时间都有效，因为我们还收到了来自这些 ajax 调用的“400 错误”响应

更新 4

我只是注意到实际上所有的错误都来自用户代理：

Mozilla webkit etc...... AdobeAIR/1.5.3这是一个非常旧的版本

我们的 AIR 应用程序只有一个 iframe 我们的网络应用程序。我只能想象那里发生了什么。

4

2 回答 2

2

好吧，我在上面的评论中错了，根据 RFC 2616，状态行的格式为：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

RFC 继续说：

Status-Code 元素是尝试理解和满足请求的 3 位整数结果代码。这些代码在第 10 节中完全定义。原因短语旨在给出状态代码的简短文本描述。状态代码供自动机使用，原因短语供人类用户使用。客户不需要检查或显示原因短语。

所以服务器可以返回“1.1 400 OK”。但这几乎不是一个精心挑选的原因短语。最好坚持使用状态代码列出的原因以避免这种混淆。（也许可以避免[过度]挑剔的客户/代理的问题。）

于 2012-08-01T21:37:07.213 回答
1

在我标记为官方答案的@pst 的好答案之后，我发现了一个更令人沮丧的答案，这对我的案例来说是 100% 正确的。

该标头是通过在 iframe 中为 Adob​​e AIR 1.5.3 的用户使用网站来实现的。

在强制升级我们所有的 AIR 用户后，它就消失了，因此可以安全地假设这是他们的标题报告的错误。

于 2012-08-27T19:05:42.017 回答