Chevnia Blog

Appearance

网络请求基础笔记 ​

1. Authorization 与 Bearer ​

HTTP 请求中的认证信息通常放在 Authorization 请求头中：

http
Authorization: Bearer YOUR_API_KEY

Authorization 是标准认证头，用于承载访问凭证。Bearer 是认证方案名称，表示后面的内容是一个“持有者令牌”。服务器只要验证该令牌有效，就认为当前请求具备相应权限。

Bearer 的核心作用是声明凭证类型。因为同一个 Authorization 头可以承载不同认证方案：

http
Authorization: Basic base64(username:password)
Authorization: Bearer access_token
Authorization: Digest ...
Authorization: AWS4-HMAC-SHA256 ...

如果没有 Bearer 前缀，服务器无法明确后面的字符串应该按哪种认证规则解析。

Bearer Token 来自 OAuth 2.0 体系，后来成为现代 API 的常见认证格式。很多 AI API 传入的是长期 API Key，不一定是严格的 OAuth access token，但仍沿用 Authorization: Bearer TOKEN_PLACEHOLDER 这一成熟约定。

这种设计的主要考虑：

  • 复用 HTTP 标准认证机制。
  • 便于网关、代理、SDK、日志系统识别敏感认证头。
  • 避免将密钥放入 URL，减少被浏览器历史、代理日志、服务端日志记录的风险。
  • 方便未来支持更多认证方案。

2. OpenAI Key 中 sk- 前缀的含义 ​

OpenAI API Key 常见格式为：

text
sk-xxxxxxxxxxxxxxxx

sk 通常可理解为 secret key 的缩写。它不是加密算法的一部分，也不是 HTTP 协议要求，而是密钥类型前缀。

这种前缀的作用：

  • 便于人和系统识别这是密钥，而不是普通 ID 或业务参数。
  • 便于安全扫描工具发现泄露的 key。
  • 便于区分不同类型的 token、项目 ID、组织 ID、公开 key 等。
  • 便于 SDK 或服务端快速判断传入格式是否合理。
  • 便于后续引入新类型凭证。

真正决定安全性的不是 sk- 前缀，而是后面随机字符串的熵、长度、权限范围、过期策略和服务端校验逻辑。

可以这样区分：

text
Bearer = HTTP 认证方案
sk-    = 密钥类型标记

3. 标准头、实验头与自定义头 ​

HTTP 头是请求或响应上的元数据字段，例如：

http
Content-Type: application/json
Authorization: Bearer xxx
User-Agent: curl/8.0

标准头是已经被正式规范或主流生态定义、语义明确、各类服务器、浏览器、代理、CDN、框架普遍理解的头。

常见标准头：

http
Content-Type: application/json
Authorization: Bearer xxx
Accept: application/json
Cache-Control: no-cache
User-Agent: Mozilla/5.0 ...
Set-Cookie: session=xxx

实验头或自定义头是特定公司、项目、系统为了扩展能力自行定义的头。历史上常用 X- 前缀表示非标准、实验性或自定义字段：

http
X-Request-ID: abc123
X-Forwarded-For: 1.2.3.4
X-API-Key: xxx
X-Trace-ID: trace-001

X- 原本表示 experimental。早期设计思路是：正式标准字段不要随意占用，自定义字段加 X- 以降低冲突概率。

后来这个规则不再被推荐作为新字段的默认命名方式。原因是很多实验头变成了事实标准，例如 X-Forwarded-For。一旦被大量系统采用，即使后来出现正式标准字段，也很难迁移。

更现代的做法是使用清晰、带命名空间的字段名：

http
OpenAI-Organization: org_xxx
Stripe-Signature: xxx
GitHub-Delivery: xxx
Acme-Request-ID: req_123

可以按以下方式理解：

类型示例说明
标准头Content-Type正式规范或主流生态定义，基础设施普遍理解
事实标准头X-Forwarded-For最初非标准，后来被广泛采用
自定义头Acme-Request-ID公司或项目内部定义
实验头X-New-Feature临时实验或灰度能力使用

4. 为什么请求需要 Header ​

一次 HTTP 请求通常分为两部分：

http
POST /v1/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer xxx
Content-Type: application/json
Accept: application/json

{
  "product_id": "p_123",
  "quantity": 2
}

上面 Host、Authorization、Content-Type、Accept 是请求头。下面的 JSON 是请求体。

核心区别：

text
Headers = 描述如何处理这次通信
Body    = 描述这次请求的业务数据

很多信息必须在读取 body 之前就知道。例如服务器需要先看到：

http
Content-Type: application/json

才能知道 body 应该按 JSON 解析。如果 Content-Type 被放在 body 里，就会形成循环：必须先解析 body，才能知道如何解析 body。

Header 的主要作用：

  • 描述 body 的格式，例如 Content-Type。
  • 描述客户端可接受的返回格式，例如 Accept。
  • 承载认证与权限信息，例如 Authorization、Cookie。
  • 控制缓存，例如 Cache-Control、ETag、If-None-Match。
  • 支持代理、网关、CDN 路由，例如 Host、Forwarded。
  • 支持链路追踪和调试，例如 Traceparent、X-Request-ID。

直观类比：

text
Headers = 快递面单
Body    = 包裹内容

快递公司不需要打开包裹，就能根据面单完成分拣、运输、追踪、签收。HTTP 的浏览器、服务器、CDN、代理、网关也通过 Header 完成基础通信处理。

5. Chrome Network 面板的基本结构 ​

Chrome 开发者工具的 Network 面板可以理解为浏览器和服务器的通信记录。一个请求通常包含：

text
General          常规摘要
Request Headers  请求标头
Response Headers 响应标头
Payload          请求载荷
Response         响应内容
Timing           耗时分析
Cookies          Cookie 信息

常规信息示例：

text
Request URL: https://mintcdn.com/.../light.svg
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:7897
Referrer Policy: strict-origin-when-cross-origin

关键字段说明：

  • Request URL：浏览器实际访问的地址。
  • Request Method：请求方法，例如 GET、POST、PUT、DELETE。
  • Status Code：服务端响应状态，例如 200、404、500。
  • Remote Address：浏览器连接到的远程地址。如果显示 127.0.0.1:端口，通常表示请求先经过本机代理。
  • Referrer Policy：控制 Referer 来源信息如何发送。

常见状态码：

text
200 成功
301 / 302 重定向
304 资源未变，使用缓存
400 请求参数错误
401 未登录或认证失败
403 无权限
404 资源不存在
500 服务端错误
502 / 503 网关或服务不可用

6. 常见请求头说明 ​

HTTP/2 和 HTTP/3 中会看到以 : 开头的伪头：

text
:authority mintcdn.com
:method GET
:path /path/to/resource
:scheme https

它们对应 HTTP/1.1 中的请求行和 Host 信息，用于描述请求目标。

常见请求头：

http
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: zh-CN,zh;q=0.9
Cache-Control: no-cache
Referer: https://example.com/
User-Agent: Mozilla/5.0 ...
Sec-Fetch-Dest: image
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site

含义说明：

  • Accept：客户端可接受的内容类型。
  • Accept-Encoding：客户端支持的压缩算法。
  • Accept-Language：客户端偏好的语言。
  • Cache-Control: no-cache：使用缓存前需要重新验证。
  • Referer：当前请求来自哪个页面。该字段是历史拼写错误，保留为 Referer。
  • User-Agent：浏览器身份信息。
  • Sec-Fetch-Dest：请求目标类型，例如 image、script、document。
  • Sec-Fetch-Mode：请求模式，例如 cors、no-cors。
  • Sec-Fetch-Site：请求来源关系，例如 same-origin、same-site、cross-site。

7. 常见响应头说明 ​

响应头是服务器或 CDN 对浏览器说明本次响应的处理规则。

常见响应头：

http
Content-Type: image/svg+xml
Content-Encoding: gzip
Cache-Control: private, no-cache
ETag: W/"263eoft2RjfDEy_A"
Last-Modified: Thu, 25 Jun 2026 09:21:07 GMT
Server: cloudflare
Cf-Cache-Status: HIT
Age: 1198552
Vary: Accept
Alt-Svc: h3=":443"; ma=86400

含义说明：

  • Content-Type：响应内容类型。
  • Content-Encoding：响应内容使用的压缩方式。
  • Cache-Control：浏览器或代理如何缓存响应。
  • ETag：资源版本标识，可用于缓存校验。
  • Last-Modified：资源最后修改时间。
  • Server：响应服务或中间层标识。
  • Cf-Cache-Status：Cloudflare 缓存状态，HIT 表示命中 CDN 缓存。
  • Age：资源在缓存中存在的秒数。
  • Vary：缓存需要根据哪些请求头区分版本。
  • Alt-Svc：提示客户端后续可使用其他协议，例如 HTTP/3。

跨域相关响应头：

http
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, OPTIONS
Access-Control-Allow-Headers: if-none-match
Access-Control-Expose-Headers: etag
Access-Control-Max-Age: 7200

含义说明：

  • Access-Control-Allow-Origin：允许哪些来源跨域访问。
  • Access-Control-Allow-Methods：跨域允许的方法。
  • Access-Control-Allow-Headers：跨域允许客户端携带的请求头。
  • Access-Control-Expose-Headers：允许前端 JS 读取的响应头。
  • Access-Control-Max-Age：预检结果缓存时间。

8. Chrome 复制请求选项 ​

Network 面板中右键请求后，会出现多种复制方式。

只复制地址：

text
复制网址

只复制请求 URL，不包含请求头、Cookie、请求体、响应内容。

复制为可重放请求：

text
以 cURL 格式复制
以 PowerShell 格式复制
以 fetch 格式复制
以 fetch (Node.js) 格式复制

用途说明：

  • 以 cURL 格式复制：生成终端可执行的 curl 命令，适合接口复现、后端排查、发给同事分析。
  • 以 PowerShell 格式复制：生成 Windows PowerShell 请求命令。
  • 以 fetch 格式复制：生成浏览器 JavaScript fetch 代码，适合在 Console 中重放请求。
  • 以 fetch (Node.js) 格式复制：生成 Node.js 环境可运行的 fetch 代码。Node.js 不受浏览器 CORS 规则约束，但也没有浏览器自动 Cookie 管理。

复制响应：

text
复制响应

复制服务器返回的响应体，例如 JSON、HTML、CSS、JS 文本等。不包含完整请求信息。

批量复制：

text
复制所有网址
以 cURL 格式复制全部内容
以 PowerShell 格式复制全部内容
以 fetch 格式复制全部内容
以 fetch (Node.js) 格式复制全部内容

这些选项会对 Network 面板当前列表中的多个请求批量复制。

HAR 格式：

text
以 HAR 格式复制所有数据（已清理）

HAR 是 HTTP Archive 的缩写，是浏览器网络记录的结构化导出格式。它通常包含：

  • 请求 URL。
  • 请求方法。
  • 请求头。
  • 请求参数。
  • 响应头。
  • 状态码。
  • 耗时。
  • 资源大小。
  • 缓存信息。
  • 时间线。

已清理 表示 Chrome 会尽量去掉部分敏感信息，但仍需要人工检查，避免泄露 Cookie、Authorization、Token 等凭证。

9. 前端调试时的观察顺序 ​

接口问题优先看：

text
Request URL
Request Method
Status Code
Payload
Response
Authorization
Cookie
Content-Type

静态资源加载问题优先看：

text
Status Code
Content-Type
Cache-Control
Size
Timing
Initiator

登录态问题优先看：

text
Cookie
Authorization
Set-Cookie
SameSite
Domain
Path

跨域问题优先看：

text
Origin
Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Headers
Access-Control-Allow-Methods

缓存问题优先看：

text
Cache-Control
ETag
If-None-Match
Last-Modified
If-Modified-Since
Status Code: 304

总结：

text
Network 面板 = 浏览器与服务器的对话记录
Request Headers = 浏览器说明请求条件
Response Headers = 服务端说明响应规则
Payload = 浏览器提交的业务数据
Response = 服务端返回的业务结果