Copy-buffer settings do not reach the HTTP/1 header-rewriting path

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

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

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

调研方向

从 src/http_proxy.rs 中的 read_header_block、copy_exact、tunnel/read-to-close copies 以及 carry-buffer allocations 开始。跟踪 #36 中的方向设置如何传递到 rewrite pumps，同时将 parser bounds 与 copy sizing 分开；选择方案前还要审查 #37。完成的标准是：rewrite routes 遵循已配置的 copy sizes，parser limits 保持固定，并更新每连接内存的文档或理由说明。

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

描述

Problem

The readBufferSize / clientReadBufferSize / upstreamReadBufferSize settings introduced in #36 govern the plain proxying path only. A route that injects HTTP headers — sourceAddressHeader: 'xForwardedFor', or forwardFingerprint: 'ja3'|'ja4' under any mode other than proxyProtocolV2 — takes http_proxy::proxy_http1_rewriting instead, which sizes its own reads:

  • read_header_block: [0u8; 4096] (src/http_proxy.rs:36)
  • copy_exact body copies: [0u8; 8192] (src/http_proxy.rs:351)
  • tunnel / read-to-close responses: unsized tokio::io::copy
  • carry buffers: Vec::with_capacity(2048)

So clientReadBufferSize: 1024 is honored on a PROXY-protocol route and silently ignored on an xForwardedFor route on the same proxy.

Impact today is bounded: the new default (8192) equals what the body copies already use, so only a raised or lowered value is a no-op, and the primary high-connection-count target (MQTT on 8883) uses PROXY protocol and takes the plain path. #36 narrowed the README and doc comments to say so rather than leaving the proxy-wide claim standing, which is why this is a follow-up rather than a blocker there.

What to do

Thread the directional sizes through the rewrite pumps, keeping two concerns separate — they are currently conflated by using one constant for both:

  • Parser bounds (how much header may be buffered before erroring) are a safety limit and should stay pinned to MAX_HEADER_SIZE / MAX_CHUNK_LINE, not follow a user-tunable copy size. A 512-byte readBufferSize must not shrink the allowed header block.
  • Copy sizing (body copies, tunnels, read-to-close) is the memory-vs-syscall trade the config is actually for, and should follow the configured per-direction size.

Note the per-connection memory shape differs on this path: the rewriting pump holds a carry Vec plus its read buffers per direction, so the (client + upstream) × connections formula from #36 will need restating for these routes once they are tunable.

Alternative

If threading them through proves to muddy the framing logic, the other honest resolution is to leave these routes fixed and keep the documentation scoped as it is now — in which case close this issue with that rationale recorded. Worth deciding rather than leaving the asymmetry undocumented in the code.

Interacts with #37 (pooling the copy buffers), which will rework the plain path's buffer lifecycle and may make a shared abstraction available to both paths.

主要语言
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 摘要。