Question

当我向URL输入一些参数时，我收到的错误有时候应该是有效请求“400 OK”。

相同的网址和参数在99％的情况下都能正常工作，但我发现日志中出现了错误。

这是一个因某些因素而可能发生的模糊事物，还是我的应用程序特有的导致奇怪标题的混合？如果前者没有答案，我猜它是后者：）

更新

对于评论，“it”是一个相对简单的RESTful API。现在它几乎总是回馈正确的标题，如400和错误的主体或200与ok的正文。当错误的标题进入Web客户端时，Web客户端正在使用它获得的消息ping报告URL，以便我们可以区分Web应用程序和移动应用程序之间的API错误。据我们所知，没有代码的组合可以使这个“400 OK”地狱。但是看到在我们的代码之外发生这种情况似乎不可能发生，我会更深入地看一下。

更新2

好的，我已经深入研究了我们的框架，而不是在很长一段时间内与一些开发者交谈。

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

浏览器检测到“400 OK”并将其发送回我们的服务器，我们收到这份奇怪的报告。没有人用他们的眼睛看到过这种情况，但是日志说它正在发生。

我们的代码库中只有零代码可以返回400 OK，因为我们的HTTP头处理程序中只有400个是“400 bad request”

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

更新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。我只能想象那里发生了什么。

Answer 1

嗯，我在上面的评论中错了，根据RFC 2616，Status Line的格式是：

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

RFC继续说：

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

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

Answer 2

在@pst得到正确回答的最佳答案之后，我发现了一个更令人沮丧的答案，对我的案子来说是100％真实。

此标题是通过使用iframe中的网站为Adobe AIR 1.5.3的用户提供的。

强制升级所有AIR用户后，它就消失了，因此可以安全地认为这是其报头报告的错误。

什么会导致HTTP发回“400 OK”

2 个答案: