Appearance
Response Headers
Response Headers 和 Request headers 类似,前者是服务器返回给客户端的响应头信息,后者是请求时客户端向服务端发送的头部信息。但值得注意,由于服务端软件差异,并非所有出现在响应中的标头都根据规范将其归类为响应标头。Response Headers是服务端软件下发的,其内容并不固定,而是根据场景来提供。并且这些Header信息中存在的字段及值都是可选以及可定义的,部分标头信息对于浏览器的优化也存在至关重要的作用。
通常,会根据场景来提供一些常用的响应头信息,这些信息将用于明确的告诉客户端服务端信息,状态,流量限制,跨域配置,缓存配置,等信息。有了这些信息浏览器或者其他客户端将根据返回的标头做进一步处理:
常见的标头
只有服务端配置了响应的标头,才会在Response Headers中显示。绝大多数服务器软件都会自动增加一些标头来保证服务器的响应信息完整。如Content-Type
字段将告知客户端当前返回内容的IMEI,这将决定性地影响客户端(浏览器)如何显示这些数据。Content-Type
一旦错误,非正常标记为HTML的时候,网页文件可能被浏览器当做无法处理的文件,弹出下载提示。
而Content-Length
算是一种标准响应字段,因为这是在规范中的,并且几乎大多数客户端都会使用到的。那什么是非标准响应字段,如X-Powered-By: PHP/5.4.0
,当服务端使用PHP开发时,响应的字段中会有 X-Powered-By
,这样的字段并不会被所有服务端下发,所以X-Powered-By
是非标准响应字段,如果不是使用PHP开发的网站,或者开发者没有特殊设置,则不会有这个字段。有的网站为了避免泄露PHP版本带来安全隐患,也会手动屏蔽。
了解和正确的使用标准响应字段十分重要,对于网站这将直接影响到缓存性能,或者跨域安全等。
GET / HTTP/1.1
200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With
Access-Control-Max-Age: 86400
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
X-Powered-By: php
Content-Type: text/html; Charset=gb2312
Set-Cookie: mykey=myvalue; expires=Mon, 17-Jul-2017 16:06:00 GMT; Max-Age=31449600; Path=/; secure
在浏览器的dev tool
中通常可以查看请求返回的Headers内容
标准响应字段
标准响应字段是指Response Headers中,根据规范定义的响应字段,这些字段几乎绝大多数的请求都会出现,但不是100%,因为业务场景不同。标准响应字段是为了规范不同客户端软件的兼容性支持,特别是浏览器等终端设备。
有的标准字段十分重要,我们也会拆解来说明。
响应头字段 | 描述 | 标准-link |
---|---|---|
Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | RFC 7233 |
Age | 从原始服务器到代理缓存形成的估算时间(以秒计,非负) | RFC 7234 |
Allow | 对某网络资源的有效的请求行为,不允许则返回405 Method Not Allowed | RFC 7231 |
Alt-Svc | 指定了在获得资源时可以使用的备用服务地址 | RFC 7838 |
Content-Disposition | 一个可以让客户端下载文件并建议文件名称的响应头 | RFC 6266 |
Content-Encoding | 告诉客户端服务端使用了什么编码方法来压缩响应数据 | RFC 7231 |
Content-Language | 呈现内容的语言 | RFC 7231 |
Content-Length | 实体主体的大小(以字节为单位) | RFC 7230 |
Content-Location | 一个可选的提示,指明了可以获取资源的另一个位置 | RFC 7231 |
Content-MD5 | 实体主体的MD5校验和,以Base64编码的结果展现,用于提供内容的校验 | RFC 1864 (已废弃,不建议使用) |
Content-Range | 在整个文件中,响应实体的位置范围,一般用于发出部分请求时使用 | RFC 7233 |
Digest | 提供了一种验证资源的方法(例如,确认下载的文件没有损坏) | RFC 3230 |
NEL | 指示资源的网络错误日志策略 | RFC 8189 |
Permissions-Policy | 控制浏览器对各种浏览器功能和API的访问策略 | 草案 |
Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | RFC 7235 |
Public-Key-Pins | 确定浏览器接受的证书链中证书的公共密钥 | RFC 7469 (已废弃,不建议使用) |
Retry-After | 如果实体暂时不可取,通知客户端在多久之后再次尝试请求 | RFC 7231 |
SourceMap | 指向一个源代码映射文件,用于调试原始资源(如压缩后的CSS或JavaScript文件) | 非标准头,由开发者工具使用 |
Strict-Transport-Security | 告知浏览器只能通过HTTPS访问网站,用于增加网站的安全性 | RFC 6797 |
Tk | Tracking Status 头用于表示请求的跟踪情况,以及是否遵守了“不要跟踪”(DNT)首部 | 草案 |
Accept-Patch | 指示服务器接受的实体类型用于PATCH请求方法 | RFC 5789 |
Accept-Post | 指示服务器接受的实体类型用于POST请求方法 | RFC 7231 |
Access-Control-Allow-Origin | 指示哪些域可以访问该资源,用于跨源资源共享(CORS) | W3C CORS |
Access-Control-Allow-Methods | 列出允许的HTTP请求方法,用于跨源资源共享(CORS) | W3C CORS |
Access-Control-Allow-Headers | 列出允许的HTTP请求头,用于跨源资源共享(CORS) | W3C CORS |
Access-Control-Max-Age | 指示预检请求(preflight request)的结果可以缓存多久,用于跨源资源共享(CORS) | W3C CORS |
Access-Control-Expose-Headers | 列出哪些头可以暴露给前端JavaScript代码,用于跨源资源共享(CORS) | W3C CORS |
Access-Control-Allow-Credentials | 指示是否允许发送Cookie等凭证信息,用于跨源资源共享(CORS) | W3C CORS |
Authentication-Info | 包含了关于认证信息的附加细节,通常用于认证过程中 | RFC 7615 |
Content-Security-Policy | 允许站点管理者控制资源哪些动态资源可以执行,减少XSS攻击的风险 | W3C CSP |
Cross-Origin-Opener-Policy | 控制跨源文档如何能够访问同一个浏览上下文中的其他文档 | 草案 |
Cross-Origin-Resource-Policy | 控制跨源资源加载的策略,用于保护资源不受恶意文档的访问 | 草案 |
Early-Data | 指示服务器是否接受在TLS握手完成之前发送的数据 | RFC 8470 |
Feature-Policy | 控制浏览器功能的使用,如摄像头、麦克风等 | 草案 |
Last-Modified | 资源最后修改的时间 | RFC 7232 |
NEL | 指示资源的网络错误日志策略 | RFC 8189 |
Permissions-Policy | 控制浏览器对各种浏览器功能和API的访问策略 | 草案 |
Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | RFC 7235 |
Public-Key-Pins | 确定浏览器接受的证书链中证书的公共密钥 | RFC 7469 (已废弃,不建议使用) |
Retry-After | 如果实体暂时不可取,通知客户端在多久之后再次尝试请求 | RFC 7231 |
SourceMap | 指向一个源代码映射文件,用于调试原始资源(如压缩后的CSS或JavaScript文件) | 非标准头,由开发者工具使用 |
Strict-Transport-Security | 告知浏览器只能通过HTTPS访问网站,用于增加网站的安全性 | RFC 6797 |
Timing-Allow-Origin | 允许服务器指定哪些源站可以访问该响应 | RFC 6454 |
非标准响应字段
非标准响应字段并没有定义在规范中,很多时候可以理解为自定义的Response Headers字段。非标准响应字段是为了满足业务场景,或者开发者特殊需求而定义的。非标准响应字段通常不会被浏览器或者其他客户端软件所使用,所以开发者需要根据业务场景来定义。此外,一些非标准响应字段也是出现频率相对较高的,如X-Powered-By
,X-Frame-Options
等,但它们并不保证所有客户端都会使用到或者有兼容性支持。有时候作为多余信息输出,但绝大多数时候是开发者根据自身需要在自研客户端加以支持的逻辑依据字段。
响应头字段 | 描述 | 相关信息 |
---|---|---|
X-Frame-Options | 控制浏览器是否允许将当前页面嵌入到另一个页面中(如iframe) | Mozilla Developer Network |
X-XSS-Protection | 启用浏览器的XSS过滤器 | Mozilla Developer Network |
X-Content-Type-Options | 阻止浏览器尝试猜测和改变响应的内容类型 | Mozilla Developer Network |
X-Powered-By | 指示服务器上使用的软件或框架 | 维基百科 |
X-UA-Compatible | 告诉浏览器以哪种文档模式来渲染页面 | Mozilla Developer Network |
X-robots-tag | 提供搜索引擎爬虫关于如何索引当前页面的指令 | Google Developers |
X-Request-ID | 用来跟踪用户请求的唯一标识符,常用于日志记录和故障排查 | 维基百科 |
X-Correlation-ID | 类似于X-Request-ID,用于跟踪和关联跨越多个服务的事务 | 维基百科 |
X-RateLimit-Limit | 限速API中,指示用户在每个时间段内可以进行的最大请求数 | GitHub Developer Documentation |
X-RateLimit-Remaining | 限速API中,指示用户在当前时间段内还可以进行的请求数 | GitHub Developer Documentation |
X-RateLimit-Reset | 限速API中,指示当前时间段结束后重置请求数的UNIX时间戳 | GitHub Developer Documentation |
结语
值得注意上面的表格中我们列举的标准响应字段并不完整,只是一些常见的用于参考,更多的还需要查阅RFC中对于这些字段的定义。