Relax SSE connection response handling

[zhxie]

This issue is similar to #393.

As described in the previous issue, a MCP server may return an error code instead of 405 Method Not Allowed when the client initializes an SSE connection for incoming events.

Previously, We have addressed this by allowing 404 Not Found response code. However, I have encountered an MCP server that responds with 400 Bad Request on the SSE connection.

When testing with MCP Inspector, it also reports a Bad Request error in thsis case, but the session proceeds normally afterward. I also checked other SDK implementations:

• Python: ignores the SSE connection when an error occurs (https://github.com/modelcontextprotocol/python-sdk/blob/db9e4515514255e7378c0e120b042dd5981ec120/src/mcp/client/streamable_http.py#L218)
• Typescript: retries several times and then ignores the error (https://github.com/modelcontextprotocol/typescript-sdk/blob/7387c44bf548b23c5cd8f1b7ae88020bfa7058ad/src/client/streamableHttp.ts#L291)
• Go: terminates the MCP session

Would it make sense to further relax the requirement to accept non-200 responses in non-strict mode? I can submit a patch if sounds reasonable.

CC @findleyr

[findleyr]

Thank you for the research. I'm ok with relaxing this condition to make the client more useful.
I'm not sure about accepting 500s: if the server is returning a 500, it seems quite plausible that there is something legitimately broken. However, interpreting a 400 as "don't allow the standalone stream" seems OK. What do you think about that? Also, there is no need to retry client errors, which keeps it simple.

Yes, please feel free to send a patch. Please mention this issue in a comment on the new logic.

In the future, we may expose a 'strict mode', but for now just doing the best we can makes sense to me.

[zhxie]

Yes, I think so. I believe relaxing it to accept 4xx responses is enough. I will open a simple PR later.