reqwest Streamable HTTP client matches response Content-Type by case-sensitive prefix
维护者通常 2 天内回复
评估
这个 Issue 还没有评估数据。
描述
Problem
The reqwest Streamable HTTP client checks response Content-Type using case-sensitive byte prefixes. This is the client-response counterpart of #1381; #1382 changes server request validation only.
On upstream 2a401c4, a local axum listener returning valid JSON-RPC or SSE payloads shows:
- POST
Application/JSONandText/Event-Streamare rejected, although media types are case-insensitive. - POST
application/jsonx,application/json-seqandtext/event-streamingare admitted as JSON/SSE rather than rejected as different types. - GET has the same case/prefix issue, including admitting comma-joined Content-Type values.
- A POST 503 carrying
Application/JSONand a valid JSON-RPC error returns opaque HTTP metadata rather than preserving that error. The newly merged 429 body-free behavior is unaffected.
RFC 9110 section 8.3.1 defines case-insensitive type/subtype names; parameters do not change the media-type essence.
Reproduction and proposed scope
I added 22 source-module tests using real axum listeners and the reqwest StreamableHttpClient methods: 12 fail on unchanged upstream, while 10 controls pass. They exercise GET, POST JSON/SSE, parameters, absent headers, suffix/list rejection and HTTP error classification.
A narrow fix can share a private exact, ASCII-case-insensitive essence matcher across the existing reqwest GET admission, POST response dispatch and JSON error classification. It would preserve the current accepted media types, parameter tolerance and 429 policy, with no dependency or API changes. The Unix-socket backend is outside this reqwest-specific proposal.
Opening this discussion before a draft implementation PR, per CONTRIBUTING. Feedback on this scope is welcome; no maintainer approval is assumed. Investigation and tests used Codex assistance.
- 主要语言
- Rust
- 星标
- 4.1k
- 派生
- 694
- 平均合并
- 3 天 14 小时
- 30 天内合并 PR
- 39
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
modelcontextprotocol/rust-sdk 的其他 Issue
-
auth: refresh_token() requests offline_access that was never granted, so refreshes fail with invalid_scope可能已有人在做 @jstar0 于 24 天前认领。 未关闭bug P1 ready for work T-security T-transport
难度 2/5 1-3 小时 新手友好度 65/100
modelcontextprotocol/rust-sdk#1330 ·
维护者通常 2 天内回复
-
OAuth discovery drops explicit default ports from advertised issuer identifiers可能已有人在做 @gocamille 于 1 天前认领。 未关闭bug P1 ready for work T-security T-transport
modelcontextprotocol/rust-sdk#1420 · 2 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
`register_client` drops `client_secret_expires_at` from the registration response可能已有人在做 @gocamille 于 3 天前认领。 未关闭bug P2 ready for work T-security
modelcontextprotocol/rust-sdk#1416 · 1 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
Typed client calls drop the parse error when a reply misses a required field可能已有人在做 @gocamille 于 3 天前认领。 未关闭enhancement P2 ready for work T-core T-service
modelcontextprotocol/rust-sdk#1415 · 1 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
-
Return merged cache hints from list_all_* client methods可能已有人在做 @gocamille 于 3 天前认领。 未关闭enhancement P2 ready for work T-service
modelcontextprotocol/rust-sdk#1411 · 1 条评论 · 已指派 1 人 ·
维护者通常 2 天内回复
查看 modelcontextprotocol/rust-sdk 的全部 Issue
相似的 Issue
-
example
难度 2/5 1-3 小时 新手友好度 72/100
rust-lang-nursery/rust-cookbook#954 ·
维护者通常 1 天内回复
-
难度 1/5 1-3 小时 新手友好度 70/100
OpenZeppelin/openzeppelin-relayer#967 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
src/runs.rs:1987: a missing --source-run-id now answers 400 "Source run ... does not exist", not 404未关闭nightly-audit
难度 2/5 1-3 小时 新手友好度 62/100
antithesishq/snouty#602 ·
维护者通常 1 天内回复