请求原文
| key | 说明 | |
|---|---|---|
| Request URL: http://localhost:8899/ollama/api/chat | 请求地址 | |
| Request Method: POST | 请求方法 | |
| Status Code: 200 OK | 请求状态码 | |
| Remote Address: [::1]:8899 | 这是服务器的远程地址。 [::1]是IPv6的回环地址，表示请求发向的是本地服务器，端口号是8899 | |
| Referrer Policy: strict-origin-when-cross-origin | 指示当跨站点请求时，Referer头部将仅包含请求的来源（协议、主机和端口），从而保护隐私 | |
| access-control-allow-credentials: true | 允许跨域请求携带凭证（如Cookie、Authorization头等） | |
| access-control-allow-origin: http://localhost:8899 | 允许来自http://localhost:8899的跨域请求。这与请求的origin匹配，符合CORS策略 | |
| content-type: application/x-ndjson | 响应内容的类型为NDJSON（Newline Delimited JSON），即每行是一个独立的JSON对象，常用于流式传输数据 | |
| date: Sat, 12 Oct 2024 03:05:59 GMT | 响应生成的时间 | |
| date: Sat, 12 Oct 2024 03:06:04 GMT | ||
| server: uvicorn | 服务器使用的Web服务器软件是Uvicorn，这是一个用于运行Python ASGI应用的高性能服务器 | |
| transfer-encoding: chunked | 响应采用分块传输编码，意味着数据会以一块一块的方式发送，适用于动态生成内容或不知道内容长度的情况 | |
| vary: Origin, Origin | 指示缓存机制在处理响应时应考虑Origin头的变化。这里出现了两次Origin，可能是配置问题。 | |
| x-process-time: 5 | 自定义头，表示服务器处理请求所花费的时间，单位通常为毫秒。这里显示5毫秒。 | |
| accept: application/json | 客户端期望服务器返回的数据格式为JSON | |
| accept-encoding: | gzip, deflate, br, zstd | 客户端支持的压缩编码格式，包括gzip、deflate、br（Brotli）和zstd（Zstandard） |
| accept-language: zh-CN,zh;q=0.9 | 客户端首选的语言是中文（中国），其次是任何中文（权重0.9） | |
| authorization: Bearer xx | 使用Bearer Token进行授权。这是一个JWT（JSON Web Token），用于验证用户身份和权限 | |
| connection: keep-alive | 表示客户端希望保持与服务器的持久连接，以便复用连接进行后续请求，提高效率 | |
| content-length: 237 | 请求体的长度为237字节 | |
| content-type: application/json | 请求体的数据格式为JSON | |
| cookie: locale=zh-cn; Phpstorm-4840e281=b96777d0-179a-4f43-be20-fd9baa9ad6cf; | 包含多个cookie信息，如locale=zh-cn（语言设置为中文），UserToken（用户身份令牌）等。这些cookie用于维持会话状态、存储用户偏好等 | |
| host: localhost:8899 | 请求的目标主机和端口。 | |
| origin: http://localhost:8899 | 表示请求的来源是http://localhost:8899，用于CORS（跨域资源共享）验证 | |
| referer: http://localhost:8899/ | 表示请求的来源页面是http://localhost:8899/。 | |
| sec-ch-ua: "Google Chrome";v="129", "Not=A?Brand";v="8", "Chromium";v="129" | 浏览器的用户代理信息，帮助服务器识别客户端使用的浏览器类型和版本 | |
| sec-ch-ua-mobile: ?0 | 表示客户端不是移动设备 | |
| sec-ch-ua-platform: "Windows" | 表示客户端操作系统平台为Windows。 | |
| sec-fetch-dest: empty | 表示请求的目的地类型为空，通常用于安全策略。 | |
| sec-fetch-mode: cors | 表示请求使用CORS模式，允许跨域请求。 | |
| sec-fetch-site: same-origin | 表示请求的源与目标是同源的，即同一个域名和端口。 | |
| user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 | 浏览器的用户代理字符串，包含浏览器类型、操作系统等信息。 |
Referrer Policy
一种用于控制在 HTTP 请求中发送的 Referer 头部的策略，决定了浏览器在发起请求时应发送多少页面来源信息（即从哪个页面发出的请求）。这可以帮助网站提升隐私和安全性，防止敏感信息泄漏。
- no-referrer
不发送任何 Referer 头，完全不向目标服务器提供来源信息。
用途：适合需要高度隐私保护的场景。 - no-referrer-when-downgrade
默认策略。如果请求是从 HTTPS 页面发往 HTTP 页面，不会发送 Referer 头。如果请求是从 HTTPS 发到 HTTPS 或从 HTTP 发到任何地址，则发送完整的 Referer 头。
用途：常见的跨协议安全机制，确保不将 HTTPS 页面的来源泄漏给不安全的 HTTP 页面。 - origin
只发送来源的域名，不包括具体的路径或参数。例如，从 https://example.com/page.html?query=123 发出请求时，Referer 头将是 https://example.com/。
用途：适用于不希望泄漏精确页面地址和查询参数，但需要提供基础域名信息的场景。 - origin-when-cross-origin
在跨域请求时只发送来源的域名，同源请求则发送完整的 URL 信息。
用途：可以在跨域时保护敏感的 URL 信息，但在同源请求中保留完整信息。 - same-origin
仅在同源请求时发送 Referer 头，跨域请求不会发送任何 Referer 信息。
用途：适合严格控制跨域信息泄漏的场景。 - strict-origin
发送来源域名，但在跨协议请求时（例如从 HTTPS 到 HTTP），不发送 Referer 头。相同协议情况下发送域名。
用途：适合在跨域时隐藏路径信息，同时在跨协议请求时进一步保护隐私。 - strict-origin-when-cross-origin
同源请求发送完整 URL，跨域请求只发送域名。如果是跨协议请求（HTTPS 到 HTTP），则不发送任何 Referer 信息。
用途：这是最常用的策略之一，提供了较好的隐私和兼容性平衡。 - unsafe-url
发送完整的 URL 信息，无论是否跨域或跨协议。所有请求都会包含完整的 Referer 头。
用途：适用于不关心隐私和安全的场景，但一般不推荐使用，因为它可能会泄露敏感的页面信息。
最严格的隐私策略：no-referrer、same-origin
适度隐私保护：origin、origin-when-cross-origin、strict-origin-when-cross-origin
默认策略：no-referrer-when-downgrade
最不安全的策略：unsafe-url (不推荐使用)
socket 区别
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13 