Hello,
While reconciling the suite's verdicts against an independent trace validator (server SUT, suite 0.1.16, spec 2025-11-25), we noticed the dns-rebinding-protection scenario performs a successful initialize on its legitimate-Host probe and then ends the session without ever sending notifications/initialized.
The 2025-11-25 lifecycle text reads: "After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations" (basic/lifecycle#initialization).
In current main (28f8338), src/scenarios/server/dns-rebinding.ts builds the probe with probeBody() (raw initialize for dated versions) and run() issues exactly two undici POSTs (evil Host → expect 4xx, valid Host → expect 2xx) and returns — no notification on the success path. (The draft-version path is fine: server/discover carries no such obligation.)
Full tapped session (suite 0.1.16 against an rmcp-based server; Host/Origin headers were the legitimate ones):
seq 0 client HTTP POST (host/origin: 127.0.0.1:<port>)
seq 1 client initialize id=1 protocolVersion=2025-11-25
seq 2 server HTTP 200 (Mcp-Session-Id issued)
seq 3 server initialize result (negotiated 2025-11-25)
— end of session —
No interop harm — surfaced only by automated runner-vs-validator reconciliation. Two possible resolutions: (a) the probe client sends notifications/initialized after a 2xx initialize (one extra POST), or (b) if the intended reading is that the obligation applies only to sessions proceeding to normal operations, the lifecycle text could say so explicitly. Happy to PR (a).
Cheers,
Tom
Hello,
While reconciling the suite's verdicts against an independent trace validator (server SUT, suite 0.1.16, spec 2025-11-25), we noticed the dns-rebinding-protection scenario performs a successful initialize on its legitimate-Host probe and then ends the session without ever sending notifications/initialized.
The 2025-11-25 lifecycle text reads: "After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations" (basic/lifecycle#initialization).
In current main (28f8338), src/scenarios/server/dns-rebinding.ts builds the probe with probeBody() (raw initialize for dated versions) and run() issues exactly two undici POSTs (evil Host → expect 4xx, valid Host → expect 2xx) and returns — no notification on the success path. (The draft-version path is fine: server/discover carries no such obligation.)
Full tapped session (suite 0.1.16 against an rmcp-based server; Host/Origin headers were the legitimate ones):
No interop harm — surfaced only by automated runner-vs-validator reconciliation. Two possible resolutions: (a) the probe client sends notifications/initialized after a 2xx initialize (one extra POST), or (b) if the intended reading is that the obligation applies only to sessions proceeding to normal operations, the lifecycle text could say so explicitly. Happy to PR (a).
Cheers,
Tom