全面分析前端的网络请求方式(5)

Request对象

Request对象接收的两个参数即fetch函数接收的两个参数，第一个参数可以直接传递url，也可以传递一个构造好的request对象。第二个参数即控制不同配置的option对象。

可以传入credentials、headers、method、mode、signal、referrer等属性。

这里注意：

• 传入的headers被当作Headers构造函数的参数来构造header对象。

cookie处理

fetch函数中还有如下的代码：

if (request.credentials === 'include') {  
    xhr.withCredentials = true  
  } else if (request.credentials === 'omit') {  
    xhr.withCredentials = false  
  }  

默认的credentials类型为same-origin,即可携带同源请求的coodkie。

然后我发现这里polyfill的实现和MDN-使用Fetch以及很多资料是不一致的：

mdn: 默认情况下，fetch 不会从服务端发送或接收任何 cookies

于是我分别实验了下使用polyfill和使用原生fetch携带cookie的情况，发现在不设置credentials的情况下居然都是默认携带同源cookie的，这和文档的说明说不一致的，查阅了许多资料后都是说fetch默认不会携带cookie，下面是使用原生fetch在浏览器进行请求的情况：

然后我发现在MDN-Fetch-Request已经指出新版浏览器credentials默认值已更改为same-origin，旧版依然是omit。

确实MDN-使用Fetch这里的文档更新的有些不及时，误人子弟了...

Response对象

Response对象是fetch调用成功后的返回值：

回顾下fetch中对Response`的操作： 

xhr.onload = function () {  
      var options = {  
        status: xhr.status,  
        statusText: xhr.statusText,  
        headers: parseHeaders(xhr.getAllResponseHeaders() || '')  
      }  
      options.url = 'responseURL' in xhr ? xhr.responseURL : options.headers.get('X-Request-URL')  
      var body = 'response' in xhr ? xhr.response : xhr.responseText  
      resolve(new Response(body, options))  
    }  

Response构造函数：

可见在构造函数中主要对options中的status、statusText、headers、url等分别做了处理并挂载到Response对象上。

构造函数里面并没有对responseText的明确处理，最后交给了_initBody函数处理，而Response并没有主动声明_initBody属性，代码最后使用Response调用了Body函数，实际上_initBody函数是通过Body函数挂载到Response身上的，先来看看_initBody函数：

可见，_initBody函数根据xhr.response的类型（Blob、FormData、String...），为不同的参数进行赋值，这些参数在Body方法中得到不同的应用，下面具体看看Body函数还做了哪些其他的操作：

Body函数中还为Response对象挂载了四个函数，text、json、blob、formData，这些函数中的操作就是将_initBody中得到的不同类型的返回值返回。

这也说明了，在fetch执行完毕后，不能直接在response中获取到返回值而必须调用text()、json()等函数才能获取到返回值。

这里还有一点需要说明：几个函数中都有类似下面的逻辑： 

var rejected = consumed(this)  
   if (rejected) {  
     return rejected  
   }  

（编辑：ASP站长网）