Add configurable limits for HTTP response bodies
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 功能
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- rust
- 领域
- cli, networking
调研方向
从 src/http.rs:141-165 开始，重点检查第 155 行的 response.into_body().collect().await，并检查现有的 request 配置和 HTTP 示例。定义如何选择限制，以及如何暴露类型化错误，然后在消费固定长度 body 和 chunked body 时强制执行该限制。完成标准是 acceptance tests 覆盖低于、等于和高于限制的情况，以及 chunked 限制，同时现有示例在受支持的 targets 上通过。
由索引模型根据 Issue 内容生成。
描述
Context
The HTTP host collects the complete response body into memory before returning it to Roc:
src/http.rs:141-165- specifically
response.into_body().collect().awaitat line 155
A slow response can be constrained with the existing request timeout, but there is no response-size limit. A server can therefore return a very large fixed-length or chunked body and cause excessive memory use or an allocation abort.
This matters for a general-purpose CLI platform because URLs and servers are often outside the application's control.
Suggested direction
Add an explicit maximum response-body size to the HTTP API. Design options include:
- a limit on the shared request configuration;
- a platform-level default plus an opt-in override;
- a separate bounded send operation.
Enforce the limit while consuming frames, rather than collecting first and checking afterward. Return a distinct typed error that callers can distinguish from malformed bodies and network failures.
A later streaming response API can be tracked separately; this issue only needs bounded buffering.
Acceptance criteria
- Callers can select or rely on a documented finite response-body limit.
- Both
Content-Lengthresponses and chunked/unknown-length responses are stopped before exceeding the limit. - Exceeding the limit returns a documented typed error rather than panicking or aborting.
- Tests cover a body just below the limit, exactly at it, above it, and a chunked body above it.
- Existing normal HTTP examples continue to pass on every supported target.
- 主要语言
- Rust
- 星标
- 121
- 派生
- 46
- 平均合并
- 12 小时 20 分钟
- 30 天内合并 PR
- 18
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
roc-lang/basic-cli 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 45/100
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
roc-lang/basic-cli#482 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 45/100
roc-lang/basic-cli#455 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 32/100
维护者通常 1 天内回复
查看 roc-lang/basic-cli 的全部 Issue
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 72/100
-
state:triage-needed
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
scanaislop/aislop#482 ·
维护者通常 1 天内回复
-
docs(skills): issue-first should reference an existing Linear ticket instead of filing a duplicate未关闭documentation
难度 1/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复