fix(server): reject a modern POST without the required MCP-Protocol-Version header (#2590)
Co-authored-by: Konstantin Konstantinov <konstantin@mach5technology.com> Co-authored-by: Konstantin Konstantinov <KKonstantinov@users.noreply.github.com>
This commit is contained in:
parent
03842cd9ca
commit
75dc7ea6e2
1 changed files with 328 additions and 43 deletions
|
|
@ -636,7 +636,19 @@ present body value, malformed, or disagree with the body — `400 Bad Request` w
|
|||
JSON-RPC `-32020` (`HeaderMismatch`). The Streamable HTTP transport also emits the
|
||||
`Mcp-Name` standard header on every modern-enveloped request, and `createMcpHandler`
|
||||
validates the SEP-2243 standard headers (`MCP-Protocol-Version`, `Mcp-Method`,
|
||||
`Mcp-Name`) against the body on the modern path with the same rejection.
|
||||
`Mcp-Name`) against the body on the modern path with the same rejection — both their
|
||||
**presence** (all three are required on every modern **request** POST; `Mcp-Name` only
|
||||
for the methods that mirror `params.name` / `params.uri`) and their agreement with the
|
||||
body. A modern-enveloped request POST that omits `MCP-Protocol-Version` is refused rather
|
||||
than served, even though the body claim alone still determines the era — so a hand-rolled
|
||||
client that relied on the body envelope without sending the header must add it. Clients
|
||||
built with this SDK send all three already.
|
||||
|
||||
Notification POSTs are exempt from the presence half: this revision defines no
|
||||
client-to-server notifications over Streamable HTTP, and states that header requirements
|
||||
for notification POSTs are not defined by it — so a modern-enveloped notification is
|
||||
dispatched and answered `202` even with no standard headers at all. Do not rely on the
|
||||
entry to reject one.
|
||||
|
||||
**Modern-era exception** to the `SdkHttpError` mapping: on a modern-enveloped request,
|
||||
an HTTP `400` whose body is a well-formed JSON-RPC error response addressed to the
|
||||
|
|
|
|||
Loading…
Reference in a new issue