返回知识库

数据与服务 · 网络与接口

HTTP 请求头HTTP Headers

HTTP headers 是附着在请求或响应上的键值元数据;按方向(仅请求/仅响应/双向)、用途与敏感性读懂,才能安全地设计、调试和缓存接口。

把 10 个真实头部按方向归位

头部不是一张平铺的字典:它有方向。请求头描述客户端带来的格式、偏好和凭据;响应头描述服务端返回的表示、缓存策略和会话属性;还有一些字段请求和响应都会出现。先把这批真实头部归位,再读为什么。

网关送来一条请求和它的响应,10 个头部散在托盘里。把每个头部按方向归位: 它只属于请求、只属于响应,还是双向都用?归位后点主操作「检查归类」。

已归位 0 / 10
仅请求0
    仅响应0
      双向0
        待归类
        • Authorization认证 / 会话
          Bearer eyJ…
        • Accept内容协商 / 表示
          application/json
        • Host路由 / 寻址
          api.example.com
        • Origin跨域
          https://app.example
        • Content-Type内容协商 / 表示
          application/json
        • Cache-Control缓存
          no-store
        • Content-Length传输
          128
        • Set-Cookie认证 / 会话
          sid=…; HttpOnly
        • ETag缓存
          "v3"
        • Location路由 / 寻址
          /login

        提示:先看用途 tag 和字段名猜方向(Accept / Authorization 偏请求,ETag / Location 偏响应),再核对 Content-Type、Cache-Control 这种请求响应都出现的双向字段。

        头部这一段装什么:方向、用途与敏感性

        面板已经把方向和敏感两条线索演给你看了,这里把规则命名清楚。

        • 位置:头部是 HTTP 消息里起始行之后、空行之前那一段,每行一个 字段名: 值;空行之后才是主体。请求和响应都有自己的头部。
        • 方向:仅请求(如 AuthorizationAcceptHost)、仅响应(如 Set-CookieETagLocation)、双向(如 Content-TypeCache-ControlContent-Length)。
        • 用途:内容协商(AcceptContent-Type)、认证会话(AuthorizationSet-Cookie)、缓存(Cache-ControlETagIf-None-Match)、跨域(Origin、CORS 头)、路由寻址(HostLocation)、传输(Content-LengthTransfer-Encoding)。
        • 敏感性AuthorizationCookie / Set-Cookie 这类高敏值只走 HTTPS,日志、追踪、错误页和分享链接都要脱敏,绝不放进 URL 查询参数
        • 大小写不敏感Content-Typecontent-type 等价;但约定写法是首字母大写,方便人读。
        • 可重复 / 可合并:多个 Set-Cookie 各占一行;Vary 等可逗号合并。自定义头现代规范已不强制 X- 前缀。

        什么时候读头部、什么时候自己写头部

        从你看到的症状或要做的事出发,而不是背字段表。

        • 调试接口:返回的格式不对、缓存不刷新、跨域被拦、登录态丢失——先打开 Network 看 Request / Response 头,比猜代码快。
        • 设计接口:要决定「这条元信息放哪」。格式走 Content-Type,鉴权走 Authorization,缓存策略走 Cache-Control / ETag,重定向走 Location,跨域走 CORS 头。
        • 决定敏感值放哪:凡是凭据、会话、个人字段,优先放头或 body,不要拼进 URL——URL 会被日志、浏览器历史和 Referer 留存。
        • 不适合单看头部:要判断「请求成功了吗」看状态码,要判断「方法是否幂等」看请求语义——头部只负责元信息,不替代它们。

        怎么读、怎么写:最短路径

        从开始到拿到判断,只走这几步。

        1. 浏览器打开 DevTools → Network → 选中一条请求。
        2. 切到 Headers 标签,分两段读:Request Headers(客户端带来的)和 Response Headers(服务端返回的)。
        3. 按用途找:格式 → Content-Type;鉴权 → Authorization / Cookie;缓存 → Cache-ControlETagIf-None-Match;跨域 → Origin / Access-Control-Allow-*;重定向 → Location
        4. 自己写时:声明真实格式、按数据敏感度选缓存指令(私人响应用 private / no-store)、把凭据放进头而非 URL,再发请求验证。

        同一份凭据:放头里,还是放 URL 里

        只改一处——token 的位置——结果差很多。这是头部最该记住的工程边界。

        正例:凭据走请求头GET /api/me HTTP/1.1Authorization: Bearer eyJ…

        token 在头部随请求发送,不进入 URL。日志、浏览器历史、Referer 都拿不到完整凭据;HTTPS 再加密传输链路。

        反例:token 塞进 URL 查询参数GET /api/me?token=eyJ… HTTP/1.1

        URL 会被网关访问日志、CDN 日志、浏览器历史、页面里的 Referer 逐一留存,还会被代理缓存键命中——凭据等于公开。改回 Authorization 头即可。

        快速自测

        你在调试一个接口,发现换语言后偶尔串数据。看 Response Headers,最该先检查哪个字段有没有写对?

        继续查证

        术语的技术定义和行为以这些一手或权威资料为准。

        下一步学

        和本知识点经常一起出现的概念。