431 and 414 responses sent by hyper or h2 never reach the Service, so metrics middleware can't record them
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 活跃
- 技术栈
- rust
调研方向
Start by reading the hyper and h2 rejection paths named in the issue: proto/h1/role.rs and proto/streams/streams.rs. Trace how each path produces a 431 or 414 and consider where the server could expose the status to applications. Done means an application can observe these responses, including their status codes, for both HTTP/1.1 and HTTP/2.
由索引模型根据 Issue 内容生成。
描述
Is your feature request related to a problem? Please describe.
When a request is too large for the server's limits, hyper (HTTP/1.1) or h2 (HTTP/2) writes the error response itself, and the request never reaches the Service. Middleware that records each request never sees these responses, for e.g. an OpenTelemetry histogram or a tracing span.
Here's what is observable today (hyper 1.12.0, h2 0.4.20):
| Protocol | Rejection | Who responds | What the application gets |
|---|---|---|---|
| HTTP/1.1 | More than max_headers headers, or a head larger than max_buf_size | hyper, 431 (Server::on_error in proto/h1/role.rs) | The connection future returns Err, and is_parse_too_large() is true |
| HTTP/1.1 | URI longer than 65,534 bytes | hyper, 414 | The same: is_parse_too_large() is true. Only the Display text, "URI too long", distinguishes it from the 431 |
| HTTP/2 | Header list larger than max_header_list_size | h2, 431 followed by RST_STREAM (Streams::recv_headers in proto/streams/streams.rs) | Nothing. The connection keeps serving other streams and ends with Ok(()) |
For HTTP/1.1 we can approximate a metric from the connection error. To tell a 414 from a 431, though, we have to match on the error's Display string, and we have none of the request's attributes, such as its method. For HTTP/2 there is nothing to hook into: no error, event or callback reaches hyper or the application when h2 answers with a 431.
Describe the solution you'd like
Some way for a server application to learn that hyper or h2 answered a request on its own, and with which status code - not entirely sure what this should look like yet.
Describe alternatives you've considered
Not aware of any other ways to solve this yet
- 主要语言
- Rust
- 星标
- 16.4k
- 派生
- 1.8k
- 平均合并
- 1 天 13 小时
- 30 天内合并 PR
- 12
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
hyperium/hyper 的其他 Issue
-
C-feature
难度 1/5 1 小时以内 新手友好度 65/100
hyperium/hyper#2652 · 4 个 reaction ·
维护者通常 1 天内回复
-
False `SendRequest` readiness for HTTP/1 connections可能已有人在做 @akasakariko 于 2 天前认领。 未关闭C-bug
难度 4/5 1-2 天 新手友好度 55/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 48/100
维护者通常 1 天内回复
-
can't upgrade request that came in with `Connection: close, Upgrade`可能已有人在做 @akasakariko 于 2 天前认领。 未关闭C-bug
难度 3/5 1-2 天 新手友好度 62/100
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
维护者通常 1 天内回复
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 78/100
swc-project/swc-next#1165 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 73/100
Alive24/shea-symphony#574 ·
-
bug tests Windows
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
documentation good first issue help wanted
难度 2/5 1-3 小时 新手友好度 74/100
dev-five-git/devup-ui#879 ·
维护者通常 11 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 77/100
farion1231/cc-switch#9038 · 1 条评论 ·
维护者通常 1 天内回复