Content-Type

Content-Type是HTTP协议的通用header，即请求和响应都可使用，用来约定请求或响应的数据类型，方便解析，具体的数据类型为/;parameter

  • type表示某一媒体类型，比如text，image，application等
  • subtype表示某一子类型，比如text/html，即text类型下的html格式
  • parameter表示一些可选参数，比如charset，boundary等

常见的Content-Type有：text/html、image/svg+xml、application/json、application/x-www-form-urlencoded、multipart/form-data，浏览器会根据响应里的Content-Type去决定以什么样的格式展示返回的内容

如果客户端需要指定服务端返回的数据格式，可以在请求header中设置Accept Header，比如

  1. Accept: text/html
  2. Content-Type: application/json

表明接收的数据类型为html格式，发送的消息主体格式为application/json

text/html
text/html一般用于请求网页页面时Accept设置的接收的数据格式

application/json
application/json一般用于post请求传输数据的格式，是比较常用的数据格式，将消息主体转化为JSON

  1. Content-Type: application/json
  3. FormData
  4. // 未编码前：name=test&password=[]123231
  5. {
  6.   "name": "test",
  7.   "password": "[]123231"
  8. }

application/x-www-form-urlencoded
一般用于post请求，表明当前消息主体类型
在原生的js中，表单提交的数据默认是该类型，它会将数据以key1=value1&key2=value2的键值对的形式组合起来，key和value都会进行URL编码

  1. Content-Type: application/x-www-form-urlencoded
  3. FormData
  4. // 未编码前：name=test&password=[]123231
  5. name=test&password=%5B%5D123231

multipart/form-data
一般用于上传文件数据，在上传文件时，调用原生的FormData，将文件file添加到formData中，发送文件时，浏览器会自动设置Content-Type: multipart/form-data，但不同浏览器设置不一样，为保险起见，可以在发送数据前手动设置Content-Type

  1. const formData = new FormData();
  2. formData.append({file: fileData});

发送数据时请求格式如下

  1. // 设置Content-Type
  2. Content-Type: multipart/form-data
  4. // 请求实体
  5. ------WebKitFormBoundaryObSQUFOR84rOU9nc
  6. Content-Disposition: form-data; name="name"
  7. test
  9. ------WebKitFormBoundaryObSQUFOR84rOU9nc
  10. Content-Disposition: form-data; name="code_data"; filename="白名单.xlsx"
  11. Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
  14. ------WebKitFormBoundaryObSQUFOR84rOU9nc--

请求实体中最前面的是boundary，是分界线，传送的数据中每一对键值对都会以boundary开头或结束
Content-Disposition用于给出相应字段的相关信息，name为传递字段名称，回车后为该字段对应的具体数据
如果传递文件等数据，会有filename表明文件的名称和Content-Type表明上传的文件类型

强缓存与协商缓存

为了避免客户端重复发起相同请求，减少服务端的响应压力，提升网页的渲染速度，设置了浏览器缓存，即将服务端的响应存储在本地磁盘中，浏览器缓存分为强缓存和协商缓存，使用HTTP的Header实现
强缓存与协商缓存的区别在于：

  • 命中强缓存时，浏览器不会发送请求，直接从缓存中拿取结果，在network里面可以看到一条响应数据，响应的状态码为200(from disk cache)

image.png

  • 命中协商缓存时，浏览器需要请求服务端，服务端根据请求的协商缓存对应header来决定客户端是否使用缓存，如果需要使用缓存，服务端返回304，表示Not Modified

image.png
强缓存可以和协商缓存共用，强缓存优先级高于协商缓存

强缓存

强缓存是指服务器返回数据时通过响应头Cache-Control和Expires来控制浏览器对数据进行缓存

  • Expires是HTTP1.0规范的Header，它的值表示资源的过期时间，是绝对时间，当用户本地时间超过该时间后，资源就过期了，就会重新请求服务端，由于用户本地时间很容易被更改且不准确，所以实际使用中会存在问题
  • Cache-Control是HTTP1.1规范的Header，它可以配置多个值来表示不同的含义
    • max-age=3600，表示资源最多在发送请求的3600秒内有效，超过这个时间就失效了
    • no-cache，表示不使用强缓存，使用协商缓存
    • no-store，表示禁止浏览器缓存数据，和浏览器中勾选disabled cache效果一样
    • public，表示浏览器和代理服务器都可以缓存资源
    • private，表示只有浏览器可以缓存资源，代理服务器不可以

Cache-Control可以同时设置多个值，比如cache-control: private, max-age=300，表示只允许浏览器缓存资源，且资源的有效期为5分钟
当Cache-Control和Expires同时存在时，Cache-Control优先级高于Expires
强缓存的缺点在于在有效时间内，数据发生修改时，浏览器是无感知的，所以强缓存一般用于长期不变动的静态资源

协商缓存

协商缓存是由服务端决定要不要使用缓存，主要由ETag、If-None-Match和Last-Modified、If-Modified-Since两组Header来控制，服务端响应数据时会带上Etag或Last-Modified，来表示服务端支持协商缓存，下一次客户端请求时会将Etag和Last-Modified的值赋给请求头If-None-Match和If-Modified-Since上，服务端会根据请求头Header来决定是否使用缓存，如果服务端没有返回Etag或Last-Modified，那客户端也不会带上If-None-Match和If-Modified-Since

  • Last-Modified/If-Modified-Since是HTTP1.0的Header，它们的值为文件最终修改时间，浏览器中请求头If-Modified-Since的值就是响应头中Last-Modified的值，服务端拿到浏览器传递的时间和文件最终修改时间进行对比，时间相同，就会返回304，此时304响应中也不会带上Last-Modified了，因为文件最终修改时间没有变化，如果资源有变化，会返回正常的响应数据，响应头中Last-Modified会带上最新的修改时间
  • ETag/If-None-Match是HTTP1.1的Header，它们的值为服务资源的唯一标识符（对文件内容进行哈希，获取信息摘要，开发者自行开发生成），只有文件内容变了，这个标识符才会变，浏览器中的If-None-Match的值就是响应头中ETag的值，与Last-Modified不一样的是，即使文件没有变化，304的响应中依旧会带上Etag

Etag主要是为了解决Last-Modified使用中文件内容没变，但修改时间变了而需要重新拉取数据的问题设计的

强缓存和协商缓存都是由服务端控制的，服务端只有在响应的Header中添加了这些Header，缓存相关的设置才会生效

参考