Problem
The Streamable HTTP transport spec says clients SHOULD send an HTTP DELETE to terminate a session and servers MAY respond 405 if they don't allow client-initiated termination. It never states what a successful termination response looks like (200? 204? any 2xx?), nor whether 404 is acceptable for a session that is already gone.
This bit us while reviewing #322 (server-session-lifecycle scenario): with no spec anchor, any strict status assertion invents a requirement. The scenario currently treats non-2xx/405 as WARNING rather than FAILURE, and 404 as already-terminated, but that's a harness judgment call, not spec.
Ask
Track here for now; this should become a clarification issue/PR on the spec repo (modelcontextprotocol) pinning the expected success status family for DELETE, and the semantics of 404 on an already-terminated session. Once the spec answers, tighten the #322 checks to match.
Problem
The Streamable HTTP transport spec says clients SHOULD send an HTTP DELETE to terminate a session and servers MAY respond 405 if they don't allow client-initiated termination. It never states what a successful termination response looks like (200? 204? any 2xx?), nor whether 404 is acceptable for a session that is already gone.
This bit us while reviewing #322 (server-session-lifecycle scenario): with no spec anchor, any strict status assertion invents a requirement. The scenario currently treats non-2xx/405 as WARNING rather than FAILURE, and 404 as already-terminated, but that's a harness judgment call, not spec.
Ask
Track here for now; this should become a clarification issue/PR on the spec repo (modelcontextprotocol) pinning the expected success status family for DELETE, and the semantics of 404 on an already-terminated session. Once the spec answers, tighten the #322 checks to match.