Correct repeated Transfer-Encoding and Content-Length response framing

未关闭
  • 哪里不对？
#32 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
52/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
rust
领域
networking

调研方向

从 src/http_proxy.rs 开始，阅读 header_field、content_length、is_transfer_encoding_chunked 和 response_body，然后跟踪由 #23 引入的 response pump。为重复和格式错误的 Transfer-Encoding 与 Content-Length 情况添加响应侧覆盖，包括每种情况后面都跟随一个 keep-alive response。完成标准是 framing、拒绝行为和 response 对应关系符合每一项验收标准。

由索引模型根据 Issue 内容生成。

描述

Follow-up from the post-merge review of #23.

Problem

The new HTTP/1 response pump uses header_field, which returns only the first field with a given name. Response framing therefore does not correctly handle repeated Transfer-Encoding or Content-Length fields.

Examples:

  • Transfer-Encoding: gzip followed by Transfer-Encoding: chunked is validly terminated by chunked framing, but the proxy sees only the first field and treats the response as read-to-close.
  • Conflicting Content-Length fields are not rejected.
  • A malformed first Content-Length becomes indistinguishable from no framing and is treated as read-to-close.

On keep-alive connections this can consume subsequent responses as part of the preceding body, break request/response correspondence, or stall until the upstream closes.

Location

  • src/http_proxy.rs: header_field, content_length, is_transfer_encoding_chunked, and response_body
  • Response pump introduced by #23.

Acceptance criteria

  • Combine all Transfer-Encoding field values in wire order and frame as chunked only when the final coding is chunked.
  • Validate every Content-Length occurrence, including comma-list normalization where supported; reject conflicting or malformed values.
  • Define and test behavior when Transfer-Encoding and Content-Length coexist in a response.
  • Add response-side tests for:
    • repeated TE ending in chunked;
    • repeated TE not ending in chunked;
    • identical repeated CL;
    • conflicting CL;
    • malformed CL;
    • each case followed by another keep-alive response to verify correspondence.
主要语言
Rust
星标
1
派生
0
平均合并
19 小时 12 分钟
30 天内合并 PR
13

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

HarperFast/symphony 的其他 Issue

查看 HarperFast/symphony 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。