1.AJAX 解决了什么问题?

在很久以前,如果浏览器需要从服务器请求资源,其交互模式为:

客户端发出请求 ==> 服务端接收请求并返回相应 HTML 文档 ==> 页面刷新,客户端加载新的 HTML文档

很显然,在这种情况下,即使只是为了更新部分数据,我们也不得不重新加载整个重绘的页面。而 AJAX 的出现解决了这个问题。

AJAX 即异步 JavaScript 和 XML,它可以在不重新加载整个网页的情况下,对网页的某部分进行异步更新。

2.XMLHttpRequest 对象

AJAX 的核心实现依靠的是浏览器提供的 XMLHttpRequest 对象。可以看作是一个构造函数,由此我们可以通过 const xhr = new XMLHttpRequest() 创建一个 XML 对象的实例,该实例有以下方法:

  • open():准备启动一个 AJAX 请求;
  • setRequestHeader():设置请求头部信息;
  • send():发送 AJAX 请求;
  • getResponseHeader(): 获得响应头部信息;
  • getAllResponseHeader():获得一个包含所有头部信息的长字符串;
  • abort():取消异步请求;

以及以下属性:

  • responseText:包含响应主体返回文本;
  • responseXML:如果响应的内容类型是 text/xml 或 application/xml,该属性将保存包含着相应数据的 XML DOM文档;
  • status:响应的 HTTP 状态;
  • statusText:HTTP 状态的说明;
  • readyState:表示“请求”/“响应”过程的当前活动阶段

3.AJAX 请求

3.1 创建 XML 对象的实例:

const xhr = new XMLHttpRequest();

3.2 准备请求

xhr.open('get','demo.php?name=Sam&job=coder',true);

open() 方法接收三个参数:请求方法,请求 URL 地址和是否为异步请求的布尔值。

  • 请求方法:有 GET 和 POST 两种,GET 请求用于向服务器拿取数据,我们可以像示例代码中那样给 URL 加上查询参数,即 ?name=Sam&job=coder,表示要查询的特定资源;POST 请求用于向服务器提交数据,数据存放的位置通过 send() 方法的参数来指定。那么,对于 GET 请求,send() 方法是否可以不传递参数呢?——不可以,应该传递 null
  • 请求 URL:可以是相对路径和绝对路径
  • 是否为异步请求:true 为异步,false 为同步。

3.3 设置请求头

xhr.setRequestHeader('Header','Value')

每个 HTTP 请求和响应都会带有相应的头部信息,包含一些与数据、收发者网络环境与状态等相关信息。
默认情况下,当发送 AJAX 请求时,会附带以下头部信息:

  • Accept:浏览器能够处理的内容类型;
  • Accept-Charset: 浏览器能够显示的字符集;
  • Accept-Encoding:浏览器能够处理的压缩编码;
  • Accept-Language:浏览器当前设置的语言;
  • Connection:浏览器与服务器之间连接的类型;
  • Cookie:当前页面设置的任何Cookie;
  • Host:发出请求的页面所在的域;
  • Referer:发出请求的页面URI;
  • User-Agent:浏览器的用户代理字符串;

另外,我们还可以通过 setRequestHeader() 方法来设置请求头信息。该函数接受两个参数:头部字段(部分默认的或者自定义的)的名称和头部字段的值。

这个方法要在 open()send() 之间调用

3.4 发送请求

xhr.send(null)
// 或者 
xhr.send(data_holder)

3.5 处理响应

目前为止,我们只是发送了请求,还没有针对服务器的响应结果做出一些处理。比方说,响应成功了怎么怎么样,响应失败了怎么怎么样。但是怎么知道是成功还是失败呢?这里就用到前面讲过的 xhr.status 属性,状态码可分为五大类:

状态码范围分类
1XX100-101信息提示
2XX200-206成功
3XX300-305重定向
4XX400-415客户端错误
5XX500-505服务器错误

当然还有具体的分类,这里不展开讲。
那么,根据 xhr.status 这个响应结果,我们就可以进行相应处理了:

...
xhr.send(null);
if ((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304) {
    alert(xhr.responseText)
} else {
    alert("Request was unsuccessful: " + xhr.status)
}

这么写对于同步请求(我们前面设置 open() 时第三个参数是 false)来说当然没问题 —— 因为是同步的,所以一定是 send 之后,服务器那边响应结果了才会继续执行后面判断 status 的代码,那么不管请求成功还是失败,这个判断一定是可以被正常执行的。但是如果是异步请求呢?对于异步请求,不需要等待服务器响应结果我们就可以执行后面的判断了,甚至可能出现一种情况是:服务器还没来得及响应结果,判断已经先执行了。那么这时候,请求一定会失败。

也就是说,我们需要加一层判断,确保收到服务器的响应结果之后,再去判断请求成功还是失败。这里就用到前面讲过的 xhr.readyState 属性,readyState 会随着 AJAX 的进程而不断变化,我们可以通过 onreadystatechange() 去监听它的变化,进而判断何时收到服务器的响应结果。

readyState 可取值有:

状态值含义说明
0未初始化尚未调用 open() 方法
1启动已经调用 open() 方法,但尚未调用 send() 方法
2发送已经调用 send() 方法,但尚未接收到响应
3接受已经接收到部分响应数据
4完成已经接收到全部响应数据,而且已经可以在客户端使用了

那么,前面的代码就变成了:

xhr.onreadystatechange = function(){
    if (xhr.readystate == 4) {
        if ((xhr.status >= 200 && xhr.status < 300) || xhr.status == 304) {
            alert(xhr.responseText)
        } else {
            alert("Request was unsuccessful: " + xhr.status)
        }
    }
}

3.6 取消异步请求

设想这么一种情况:我们正在上传一张图片(也就是发送一个 AJAX 请求),由于耗时过长,我们决定取消上传,那么取消上传其实就是取消 AJAX 请求,这是通过 abort() 方法实现的。一旦调用这个方法,xhr 就会停止触发事件,而且也不再允许访问任何与响应相关的对象属性。在终止请求之后,不要忘了对 xhr 对象解引用。

正常上传:

取消上传:

4.XMLHttpRequest 2 级

4.1 FormData

通常提交表单数据的时候,这些数据需要经过序列化,虽然 $('#form').serialize() 可以实现序列化,但对于文件流无能为力。而 FormData 不仅可以做到表单序列化,而且支持异步上传二进制文件。

var data = new FormData();
data.append('name','Sam');
// or
var data = new FormData(document.forms[0]);

4.2 超时设定

xhr.timeout 指定一个毫秒为单位的时间,一旦浏览器在这个规定的时间内没有收到响应,就会触发 timeout 事件,执行回调函数。

xhr.onreadystatechange = function () {
  if(xhr.readyState == 4){
    try{
      if((xhr.status >= 200 && xhr.status <300) || xhr.status == 304){
        alert(xhr.responseText);
      }else{
        alert("Request was unsuccessful:" + xhr.status);
      }
    } catch(ex){
      //......
    }
  }
}
xhr.open('get','timeout.php',true);
xhr.timeout = 1000;
xhr.ontimeout = function () {
  alert("Request did not return in a second");
};
xhr.send(null);

注意:这时候很可能出现一种情况,就是超过1秒后浏览器没收到响应,因此终止了请求,而这时候恰好 xhr.status 为4,因此又调用函数进行判断,这个判断需要访问 xhr.status 属性,而请求已经被终止,这个属性是无法访问的,此时要用 try...catch... 捕获这个错误。

4.3 overrideMimeType() 方法

服务器返回的响应头中有一个是 Content-Type,用以告诉客户端返回的资源类型(MIME)以及应该用什么编码去解码。例如 Content-Type:text/html;charset=UTF-8,那么客户端就会通过 UTF-8 对资源进行解码,然后对资源进行 HTML 解析。
但可能存在一种情况:虽然服务器返回数据是 XML,但 MIME 类型指定为 text/plain,那么这时候客户端就会当作纯文本去处理了,这显然不对,所以我们可以利用 overrideMineType() 方法重写响应的 MIME 类型,这样,客户端就可以将其当作 XML 去处理了。

var xhr = new XMLHttpRequest();
xhr.open('get','text.php',true);
xhr.overrideMineType('text/xml');
xhr.send(null);

注意,必须在 send 调用之前重写。

4.4 进度事件

Progress Events规范规范定义了与客户端与服务器通信相关的一系列事件,这些事件监听了通信进程中的各个关键节点,使我们能够以更细的颗粒度掌控数据传输过程中的细节。有以下6个进度事件:

  • loadstart:在接受到响应数据的第一个字节时触发
  • progress:在接受响应期间持续不断地触发
  • error:在请求错误时触发
  • abort:在因为调用 abort() 方法而终止连接时触发
  • load:在接收到完整的响应数据时触发
  • loadend:在通信完成或触发 error、abort、load 事件后触发

每个请求都从触发 loadstart 事件开始,接下来是一或多个 progress 事件,然后触发 error、abort 或 load 中的一个,最后以触发 loadend 事件结束。

有没有发现,前面的 xhr.readyState == 4 以及这里的 load 事件都可以判断是否接受到完整响应? load 事件实际上简化了这个过程,它不需要像前者那样,既绑定一个监听函数又做一次 readyState 的判断,而只需要绑定监听函数即可。

xhr.onreadystatechange = function () {
  if(xhr.readyState == 4){
    //....
  }
}
// 变成
xhr.onload = function () {
    //....
}

5.同源策略

浏览器的同源策略即 Same-Origin Policy (SOP),它限制了不同源之间执行特定操作。

5.1 源

一个源由协议端口域名组成,只要有一个不同,就认为是不同源。

http://test.com/dist/demo.html 为例,不同源以及同源可能有以下情况:

类型URL结果
不同协议https://test.com/dist/demo.html失败
不同端口http://test.com:80/dist/demo.html失败
不同域名http://test.cn/dist/demo.html 或者 http://www.test.com/dist/demo.html失败
不同路径http://test.com/dist2/demo.html成功

5.2 特定操作

特定操作指的是:

  • 读取 Cookie、LocalStorage、IndexedDB
  • 获取 DOM 元素
  • 发送 AJAX 请求

为什么同源策略要禁止不同源之间进行这些操作呢?我们不妨假设一下,不存在同源策略、且不同源之间这些操作是允许的,看看可能会发生什么事。

  • 如果 A 源可以读取 B 源的 Cookie、LocalStorage、IndexDB,那么等于 B 源存储的信息都暴露了,那将毫无隐私可言。所以同源策略禁止不同源之间读取 Cookie、LocalStorage、IndexDB;

  • 如果 A 源可以获取 B 源的 DOM 元素,那么假定用户访问了在 A 源中用 iframe 引入的 B 源网页,他的所有操作就都会在我们的掌握之中,因为我们可以在 A 源操作 B 源的 DOM 元素;

  • 如果 A 源可以自由发送 AJAX 请求给 B 源,那么可能会遇到 CSRF 攻击。假定现在有一个用户首先登录了 Bank.com,那么本地客户端就会保存这个网站的 Cookie (里面记录了用户在该网站的身份信息)。之后用户不小心点进了危险网站 Evil.com,这个网站做了一些设置,一旦用户进入,就自动发送 AJAX 请求给 Bank.com,由于发送请求的时候,浏览器会自动在本地检索目标网站的 Cookie ,并添加到请求报文中随着请求一起发送给目标网站,所以目标网站检测到 Cookie 确实没问题,就会响应这个请求 —— 而这个请求实际上可能执行了类似删除数据这样的敏感操作。

6.跨域通信

这样看来,同源策略确实很有存在的必要,不然网络安全无从谈起。

等等,既然有同源策略的限制,那 A 源怎么去请求 B 源的数据呢?

我们知道,第三方接口通常都是运行在单独的服务器上的。比如说,当前 web 页面运行在 http://test.com/index.html 这个服务器地址上,页面需要访问的接口运行在 http://api.test.com 这个服务器地址上。那么,通过浏览器访问 web 页面的时候,浏览器会针对接口地址发起 AJAX 请求,相当于 A 域需要请求 B 域的资源。

但同源策略是禁止这种行为的,这样的话我们要怎么进行跨域通信呢?

参考: