记一次BUG到XMLHttpRequest对象的status与readyState

今天项目中，接收node服务器发送的数据完成页面渲染时，迟迟接收不到，Console栏里也没有报错信息，很是奇怪。于是开始和BUG的相爱相杀之旅。

1 首先打印服务器是否已经发送数据，发现数据已经发送出去，于是去检查客户端

2 查看客户端交互部分代码，如下：

static readStateHandler(e) {
        let xhr = e.currentTarget;
        console.log(xhr.response);
        if (xhr.readyState === 4 && xhr.status === 200) {
            try {
                AJAX.data = JSON.parse(xhr.response);
            } catch (e) {
                AJAX.data = QueryString.parse(xhr.response);
            }
        } else if (xhr.readyState === 4 && xhr.status !== 200) {
            console.error("error===============");
        }
}

3 打印xhr.response，无误。这就很骚了。

4  数据到了，难道没设置进去？为什么不报错？于是检查设置数据的判断条件xhr.readyState和xhr.status。发现没有到4。意味着本次通信一直处于处理状态，没有到完结状态。有数据，根据以上代码逻辑，服务器没有完成相应，状态值没有到4是不会进行数据设置的。最后发现服务器端没有写req.end()，添上即可让本次通信完成时处于完结状态，readyState处于4.

 Ajax状态值(readyState)和状态码(status)

为什么判断服务器响应，既要用到状态值，也要用到状态码?

1 只用状态值readyState：

• 如果服务器出错，返回的不是200，而是500，还是会发送响应数据，造成不可预知的错误

2 只用状态码status:

• 从通信开始到完成，状态值一共会经历0-4的改变，分别代表通信所处的几种状态。
• 如果只判断状态码，不判断状态值，就会出现，如果请求正在处理(readyStatus=3)，尚未完成，但是服务器已经发送了一条数据的语句，状态码为200，此时客户端就会获取数据去进行渲染。当请求处理完成了，readyStatus=4,此时如果发送了响应数据，由于状态码是200，客户端又会重新获取数据进行数据渲染。

3 总结

• 只用readyState,会出现服务器出错依然发送响应数据的情况。
• 只用status,会出现客户端接收了服务器尚未全部完成请求处理时发送的数据的情况。

readyState:ajax通信时经历的几种状态.通过访问xmlHttpRequest对象下的readyState属性获取

0：请求未初始化，还没有调用 open()。

1：请求已经建立，但是还没有发送，还没有调用 send()。

2：请求已发送，正在处理中（通常现在可以从响应中获取内容头）。

3：请求在处理中；通常响应中已有部分数据可用了，没有全部完成。//示例bug在于此

4：响应已完成；您可以获取并使用服务器的响应了。

status:是响应的http状态码，在http中，http状态码可以分为5大类

1xx：信息提示

• 100：Continue初始的请求已经接受，客户应当继续发送请求的其余部分
• 101：Switching Protocols 服务器将遵从客户的请求转换到另外一种协议

2xx ：成功

• 200 ：OK   一切正常，后面是GET或POST请求的应答文档
• 201：createed 服务器已经创建了文档，location头给出了url
• 202：Accepted  已经接收了请求，但是还没处理完成
• 203 ：Non-Authoritative Information 文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝，非权威性信息（HTTP 1.1新）
•  204： No Content 没有新文档，浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
• 205：Reset Content 没有新的内容，但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容（HTTP 1.1新）。
• 206：Partial Content 客户发送了一个带有Range头的GET请求，服务器完成了它（HTTP 1.1新）。

 

3xx：重定向。客户端浏览器需要请求服务器上的不同页面来完成请求

• 300 - Multiple Choices 客户请求的文档可以在多个位置找到，这些位置已经在返回的文档内列出。如果服务器要提出优先选择，则应该在Location应答头指明。
• 301 - Moved Permanently 客户请求的文档在其他地方，新的URL在Location头中给出，浏览器应该自动地访问新的URL。
• 302 - Found 类似于301，但新的URL应该被视为临时性的替代，而不是永久性的。注意，在HTTP1.0中对应的状态信息是“Moved Temporatily”。出现该状态代码时，浏览器能够自动访问新的URL，因此它是一个很有用的状态代码。注意这个状态代码有时候可以和301替换使用。例如，如果浏览器错误地请求 http://host/~user （缺少了后面的斜杠），有的服务器返回301，有的则返回302。严格地说，我们只能假定只有当原来的请求是GET时浏览器才会自动重定向。请参见307。
• 303 - See Other 类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向目标文档应该通过GET提取（HTTP 1.1新）。
• 304 - Not Modified 客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
• 305 - Use Proxy 客户请求的文档应该通过Location头所指明的代理服务器提取（HTTP 1.1新）。
• 307 - Temporary Redirect 和302（Found）相同。许多浏览器会错误地响应302应答重定向，即使原来的请求是POST，即使它实际上只能在POST请求的应答是303时才能重定向。由于这个原因，HTTP 1.1新增了307，以便更加清除地区分几个状态代码：当出现303应答时，浏览器可以跟随重定向的GET和POST请求；如果是307应答，则浏览器只能跟随对GET请求的重定向。（HTTP 1.1新）

4xx：客户端错误。客户端有问题，如请求不存在的页面、客户端未提供有效的身份验证信息等

最常见的是404：没有找到文件或目录，一般是路径问题。

• 403.1 - 执行访问被禁止。
• 403.2 - 读访问被禁止。

 

• 403.3 - 写访问被禁止。
•  403.4 - 要求 SSL。
• 403.5 - 要求 SSL 128。
• 403.6 - IP 地址被拒绝。
• 403.7 - 要求客户端证书。
• 403.8 - 站点访问被拒绝。
• 403.9 - 用户数过多。
• 403.10 - 配置无效。
• 403.11 - 密码更改。
•  403.12 - 拒绝访问映射表。
•  403.13 - 客户端证书被吊销。
• 403.14 - 拒绝目录列表。
• 403.15 - 超出客户端访问许可。
• 403.16 - 客户端证书不受信任或无效。
• 403.17 - 客户端证书已过期或尚未生效。
• 403.18 - 在当前的应用程序池中不能执行所请求的 URL。这个错误代码为 IIS 6.0 所专用。
• 403.19 - 不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。
• 403.20 - Passport 登录失败。这个错误代码为 IIS 6.0 所专用。
• 404 - Not Found 无法找到指定位置的资源。这也是一个常用的应答。
• 404.0 -（无） – 没有找到文件或目录。
• 404.1 - 无法在所请求的端口上访问 Web 站点。
• 404.2 - Web 服务扩展锁定策略阻止本请求。
• 404.3 - MIME 映射策略阻止本请求。

5xx：服务器错误。服务器由于遇到错误而不能完成该请求

• 500：Internal Server Error 服务器遇到了意料不到的情况，不能完成客户的请求。
• 502：Bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。 亦说Web 服务器用作网关或代理服务器时收到了无效响应。
• 503：服务不可用。服务器由于维护或者负载过重无法应答。
• 504：Gateway Timeout 网关超时，由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。
• 505： HTTP Version Not Supported 服务器不支持请求中所指明的HTTP版本。