Session 详情增加记录实际转发的请求头和响应头

[ding113]

现在的 Session 详情只记录了请求体和响应体。
希望增加记录 CCH 修改后实际转发的，实际发往供应商的请求头和响应头。
并且在 Session 详情页面，从上下并排改为 tab 切换显示请求头，请求体，响应头和响应体。优化显示体验。

对 API Key 字段做隐去处理。

相同地，存储于 Redis 中，随会话过期而删除。保证隐私。

[github-actions]

Thank you for this feature suggestion.

Feasibility Assessment

Based on my analysis of the codebase, this feature request is technically feasible and aligns well with the existing architecture.

Current Implementation

The Session details page currently displays:

• Request body (messages) - stored via SessionManager.storeSessionMessages() (src/lib/session-manager.ts lines 850-881)
• Response body - stored via SessionManager.storeSessionResponse() (src/lib/session-manager.ts lines 1256-1282)
• Session metadata (tokens, cost, duration, providers) - aggregated from database

The UI component at src/app/[locale]/dashboard/sessions/[sessionId]/messages/_components/session-messages-client.tsx (lines 273-346) currently uses a vertical layout displaying request messages and response body in sequence.

Relevant Code for Implementation

1. Headers are already captured during proxy processing:

• src/app/v1/_lib/proxy/session.ts (line 51-52, 125-126): Request headers are captured in ProxySession with headers and headerLog properties
• src/app/v1/_lib/proxy/forwarder.ts (lines 1786-1868): buildHeaders() constructs the actual headers sent to providers
• Response headers are available in src/app/v1/_lib/proxy/response-handler.ts from the upstream response

2. Redis storage pattern exists:

• Current session data keys: session:{sessionId}:info, session:{sessionId}:messages, session:{sessionId}:response
• New keys would follow: session:{sessionId}:req:{sequence}:request_headers, session:{sessionId}:req:{sequence}:response_headers

Implementation Considerations

1. API Key Masking: The sanitizeHeaders() function in src/app/v1/_lib/proxy/errors.ts (lines 950-985) already implements header sanitization including masking of sensitive values like Authorization and x-api-key. This pattern should be reused.

2. Storage: Following the existing pattern, headers would be stored in Redis with the same SESSION_TTL (5 minutes default), ensuring privacy as requested.

3. UI Changes: The proposed tab-based layout would improve the display experience. The current Section component pattern supports actions and could be extended for tabs.

Dependencies

• src/lib/session-manager.ts - Add new store/retrieve methods for headers
• src/app/v1/_lib/proxy/forwarder.ts - Capture processed headers before forwarding
• src/app/v1/_lib/proxy/response-handler.ts - Capture response headers
• src/actions/active-sessions.ts - Extend getSessionDetails() to return headers
• src/app/[locale]/dashboard/sessions/[sessionId]/messages/_components/session-messages-client.tsx - UI update to tab layout

---

Automated response from Claude AI

[github-actions]

感谢这个改进建议（在 Session 详情里补充“实际转发”的请求/响应头，并用 tab 优化展示）。

目前 Session 详情的数据来源（代码已验证）

• 后端 getSessionDetails() 目前只返回 messages 和 response（另有 DB 聚合的 sessionStats）：src/actions/active-sessions.ts（L508-L591）

const [messages, response, requestCount] = await Promise.all([
  SessionManager.getSessionMessages(sessionId, requestSequence),
  SessionManager.getSessionResponse(sessionId, requestSequence),
  SessionManager.getSessionRequestCount(sessionId),
]);

• messages 仅在 STORE_SESSION_MESSAGES=true 时才会写入/读取 Redis：src/lib/session-manager.ts（L24-L25, L850-L875, L1162-L1191）
• response 会按 session:${sessionId}:req:${sequence}:response 写入 Redis，并随 SESSION_TTL 过期：src/lib/session-manager.ts（L24, L1256-L1272, L1291-L1310）
• 前端详情页当前仅纵向展示“请求 messages / 响应 body”两个区块：src/app/[locale]/dashboard/sessions/[sessionId]/messages/_components/session-messages-client.tsx（L290-L336）

“实际发往供应商”的请求头/响应头：可以抓取的位置

• 出站请求头最终由 ProxyForwarder.buildHeaders() 生成（并注入了供应商 provider.key 到 authorization/x-api-key）：src/app/v1/_lib/proxy/forwarder.ts（L1786-L1869）

const overrides: Record<string, string> = {
  host: HeaderProcessor.extractHost(provider.url),
  authorization: `Bearer ${outboundKey}`,
  "x-api-key": outboundKey,
  "content-type": "application/json",
};

• Gemini 分支同样会构造认证头：src/app/v1/_lib/proxy/forwarder.ts（L954-L976）
• 入站响应头在 undiciFetchNoDecompress() 中从 undiciRes.headers 组装为 responseHeaders，并在 gzip 场景下删除了 content-encoding/content-length 后返回：src/app/v1/_lib/proxy/forwarder.ts（L1954-L2030）

隐私/脱敏注意点

• 因为请求头里明确包含 authorization / x-api-key（以及 Gemini 的 API key header），如果要存 Redis 并在 UI 展示，建议至少对这些字段做脱敏/省略后再落盘：src/app/v1/_lib/proxy/forwarder.ts（L1794-L1806, L967-L971）

UI tab

• 代码库已有 Tabs 组件可复用：src/components/ui/tabs.tsx（导出 Tabs, TabsList, TabsTrigger, TabsContent）

需要确认两点，方便把需求落到一致的“应记录的头”上

1. “响应头”希望展示的是上游供应商返回给 CCH 的 headers（ProxyForwarder 处拿到的），还是最终回给客户端的 headers（ProxyForwarder.send() 之后还会进入 ProxyResponseHandler.dispatch()：src/app/v1/_lib/proxy-handler.ts L78-L79）？
2. 除了 API key 相关字段外，是否还需要对其他 header 做脱敏/过滤（例如完全不展示某些 header 名）？

---

Automated response from Codex AI