fix: export jsonResponse field

[CCpro10]

StreamableHTTPOptions.JsonResponse should be exported.

[CCpro10]

@jba @findleyr Could you please take a look at this PR when you have a moment? Thanks!

[findleyr]

Why should JsonResponse be exported? What is the use-case?

The reason it is unexported is that we didn't understand why it is necessary.
(I think one potential use case is proxy support for text/event-stream. Is that your use-case?)

[CCpro10]

Why should JsonResponse be exported? What is the use-case?

The reason it is unexported is that we didn't understand why it is necessary. (I think one potential use case is proxy support for text/event-stream. Is that your use-case?)

Thanks for asking for clarification.
JsonResponse should be exported because it's an optional field that needs to be assigned during initialization. For example, if JsonResponse is a boolean flag or a specific configuration related to how the server should format its messages, I need to be able to set that value from outside the package when initializing the StreamableHTTPOptions.
If it remains unexported, how would the server be able to reply in JSON format for the SSE stream, or how could I enable/disable that behavior? Without being able to assign it, the feature it represents becomes unusable from an external package.

[findleyr]

@CCpro10 my question is really why the server needs to reply with application/json.

I'm not sure what you mean by "reply in JSON format for the SSE stream". Do you mean "reply with application/json rather than text/event-stream"?

Can you clarify why you need to have your server reply with application/json?

[CCpro10]

@findleyr "Yes, that's correct. My intention is for the server to reply with application/json rather than text/event-stream. If the server supports application/json for these responses, it would make the MCP client much easier to handle."

"As per the official MCP documentation, it states:
'If the input contains any number of JSON-RPC requests, the server MUST either return Content-Type: text/event-stream, to initiate an SSE stream, or Content-Type: application/json, to return one JSON object. The client MUST support both these cases.'"

"Therefore, enabling the server to respond with application/json (by allowing configuration via the JsonResponse field) is a valid and explicitly supported option according to the protocol."

[findleyr]

@CCpro10 yes, the spec states that the server must return one of text/event-stream or application/json. The SDK, by default, returns text/event-stream. When I added jsonResponse, I was asked why it was needed, when always preferring text/event-stream also conforms to the spec.

What is your client? If you are using a spec-conformant client, then it must support text/event-stream, and therefore it also doesn't matter from the client's perspective. Put differently, if your client needs to connect to servers that you don't control, then it must support text/event-stream.

I'm not opposed to exposing JSONResponse, but I'd like to have a real reason to do so. Again, it was originally exported in the CL that added it, but I didn't have a good reason for it. So I'd like to understand your use-case better.

FWIW, I do hear that some proxies have trouble with text/event-stream, so maybe that's a good enough reason, but it sounds like that's not the reason you need it.

[CCpro10]

@findleyr
"This is how mark3labs/mcp-go handles requests: it defaults to application/json, and only upgradeToSSE when sending notifications before a response. I believe this behavior is very reasonable."
"Regarding the reasons you mentioned, simply put, the MCP server needs full control over its behavior. Therefore, this field (JsonResponse) should either be exported or removed entirely. An unexported field in this context is both confusing and aesthetically poor (or 'ugly' in a less formal sense)."

[findleyr]

@CCpro10 I think defaulting to application/json and upgrading to SSE would be fine, though it's not trivial. I can send a CL implementing that.

I'll file a proposal for exporting JSONResponse, to discuss if there are use cases. If not, we can remove it.

[CCpro10]

@findleyr OK, that's great

[findleyr]

Actually, in #211, there was some feedback about the necessity of this for an MCP gateway, which I think is the same feedback as we'd heard about proxies.

Therefore, I reopened that proposal, and we can merge this (we'll leave the proposal open for some time).

[CCpro10]

@findleyr I have revised the code as you requested. Json --> JSON