HTTP状态代码0是否有任何意义？

简短回答

它不是HTTP响应代码，但WhatWG将其记录为XMLHttpRequest或Fetch响应的status属性的有效值

广义地说，它是在没有要报告的realHTTP状态代码和/或发送请求或接收响应时发生的错误时使用的默认值。这种情况下的可能场景包括但不限于：

• 请求尚未发送，或已中止
• 浏览器仍在等待接收响应状态和标题
• 请求期间连接已断开
• 请求超时
• 请求遇到无限重定向循环
• 浏览器知道响应状态，但由于与同源策略相关的安全限制，不允许您访问响应状态

长话短说

首先，重申：0不是HTTP状态码。RFC 7231第6.1节中有一个完整的列表，其中不包括0，第6节的介绍清楚地指出

状态代码元素是一个三位整数代码

其中0不是

但是，0作为XMLHttpRequest对象的.status属性的值是有文档记录的，尽管跟踪所有相关细节有点棘手。我们从https://xhr.spec.whatwg.org/#the-状态属性，记录.status属性，该属性仅说明：

status属性必须返回响应的状态

这听起来可能空洞而重复，但实际上这里有信息！请记住，本文档在此讨论的是XMLHttpRequest的.response属性，而不是响应，因此这告诉我们，XHR对象上状态的定义将延迟到Fetch规范中响应状态的定义

但什么是回应对象？如果我们还没有收到回复呢？“单词”上的内联链接；回应”；带我们去https://xhr.spec.whatwg.org/#response，解释如下：

XMLHttpRequest具有关联的响应。除非另有说明，否则这是网络错误

因此，我们得到的响应状态默认为网络错误。通过到处搜索短语“；将响应设置为&quot在XHR规范中使用，我们可以看到它设置在五个位置：

• 当出现以下情况时，会导致网络错误：

  • 调用open（）方法，或
  • 响应主体的流出错（请参阅文档中描述的send（）方法的算法）
  • 设置超时标志，导致运行请求错误步骤
  • 调用abort（）方法，导致运行请求错误步骤

• 通过Fetch进程响应任务（如果XHR请求是非同步的）或Fetch进程响应结束正文任务（如果XHR请求是同步的），使用Fetch发送请求所产生的响应

查看Fetch标准，我们可以看到：

网络错误是一种状态始终为0

因此，我们可以立即看出，在XHR规范指出响应应设置为网络错误的任何情况下，XHR对象上的状态都将为0。（有趣的是，这包括主体的流“出错”的情况，Fetch规范告诉我们在主体收到状态后解析主体时可能会发生这种情况，因此理论上我认为XHR对象可能会将其状态设置为200，然后在接收时遇到内存不足错误或其他情况。）正在删除主体，因此将其状态更改回0。）

在Fetch标准中，我们还注意到存在两种其他响应类型，其状态定义为0，其存在与跨源请求和同源策略有关：

不透明过滤响应是一个过滤响应，其。。。状态为0

不透明重定向筛选响应是一个筛选响应，其。。。状态为0

（省略了关于这两种响应类型的各种其他细节）

但除此之外，还有许多情况下Fetch算法（而不是我们已经看过的XHR规范）会要求浏览器返回网络错误！事实上，这句话是；返回网络错误“；在提取标准中显示40次。我不会在这里列出所有40个，但我注意到它们包括：

• 请求的方案无法识别的情况（例如，试图向mad发送请求eupscheme://foobar.com)
• “非常模糊的指令”；如有疑问，请返回网络错误。”；在处理ftp://和file://URL的算法中
• 无限重定向：“无限重定向”；如果请求的重定向计数为20，则返回网络错误
• 一系列与CORS相关的问题，例如；如果httpRequest的响应污染不是；cors&quot；请求和响应返回被阻止的跨源资源策略检查，然后返回网络错误。”
• 连接失败：&quot；如果连接失败，则返回网络错误

换言之：每当出现问题时，除了从服务器获取真实的HTTP错误状态代码（如500或400），XHR对象或浏览器中的Fetch response对象上的status属性为0。spec中列举的可能的特定原因数量是巨大的

最后：如果您出于某种原因对规范的历史感兴趣，请注意，这个答案在2020年被完全重写了，您可能对这个答案的先前版本感兴趣，它解析了旧的（而且更简单）W3规范XHR的基本相同结论，在这些被更现代、更复杂的WhatWG规格所取代之前，这些答案所指的是什么