optimization: When using custom SSE request,Authorization header can still be automatically attached to the SSE request.

[chenxi-null]

When using the custom SSE request, the Authorization header can still be automatically attached to the SSE request.

Motivation and Context

Current:
When user customizes the initial SSE request, it will prevent an Authorization header from being automatically attached to the SSE request. It require user to fetch tokens from authProvider and set the Authorization header manually.
Ref:

typescript-sdk/src/client/sse.ts

Lines 36 to 44 in bced33d

	/**
	* Customizes the initial SSE request to the server (the request that begins the stream).
	*
	* NOTE: Setting this property will prevent an `Authorization` header from
	* being automatically attached to the SSE request, if an `authProvider` is
	* also given. This can be worked around by setting the `Authorization` header
	* manually.
	*/
	eventSourceInit?: EventSourceInit;

Goal:
Simplify the code and reduce the risk of misuse.
There is an misused case: CherryHQ/cherry-studio#5709

How Has This Been Tested?

npm test -- src/client/sse.test.ts -t "refreshes expired token during SSE connection"

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[ochafik]

Hi @chenxi-null, thanks for sending this out! I took the liberty to refactor / simplify the code a bit, let me know your thoughts :-)

[ochafik]

Not sure this belongs here?

[chenxi-null]

I want to make the .vscode folder untracked by Git.

[ochafik]

There's now some conflicts coming in from main onto the tests, could you have a look?

[chenxi-null]

There's now some conflicts coming in from main onto the tests, could you have a look?

@ochafik Okay, I'll resolve the conflicts.

[chenxi-null]

@ochafik I have resolved the code conflicts.

By the way, I find a test case failure which is already existed in main branch. So I can't pass all test cases, but it's caused by the other code in main branch. It need someone else to fix it.

Summary of all failing tests
FAIL src/server/sse.test.ts
● SSEServerTransport › start method › should pass request info to tool callback

expect(jest.fn()).toHaveBeenCalledWith(...expected)

Expected: "event: message
data: {\"result\":{\"content\":[{\"type\":\"text\",\"text\":\"Hello, Test User!\"},{\"type\":\"text\",\"text\":\"{\\\"headers\\\":{\\\"host\\\":\\\"127.0.0.1:56147\\\",\\\"connection\\\":\\\"keep-alive\\\",\\\"content-type\\\":\\\"application/json\\\",\\\"accept\\\":\\\"application/json, text/event-stream\\\",\\\"accept-language\\\":\\\"*\\\",\\\"sec-fetch-mode\\\":\\\"cors\\\",\\\"user-agent\\\":\\\"node\\\",\\\"accept-encoding\\\":\\\"gzip, deflate\\\",\\\"content-length\\\":\\\"124\\\"}}\"}]},\"jsonrpc\":\"2.0\",\"id\":\"call-1\"}·
"
Received
       1: "event: endpoint
data: /messages?sessionId=457d8970-3b84-4ed1-b8cc-62c196bd64fb·
"
       2: "event: message
data: {\"result\":{\"protocolVersion\":\"2025-03-26\",\"capabilities\":{\"logging\":{},\"tools\":{\"listChanged\":true}},\"serverInfo\":{\"name\":\"test-server\",\"version\":\"1.0.0\"}},\"jsonrpc\":\"2.0\",\"id\":\"init-1\"}·
"
       3: "event: message
data: {\"method\":\"notifications/tools/list_changed\",\"jsonrpc\":\"2.0\"}·
"

Number of calls: 4

  326 |       id: "call-1",
  327 |     };
> 328 |     expect(mockRes.write).toHaveBeenCalledWith(`event: message\ndata: ${JSON.stringify(expectedMessage)}\n\n`);
      |                           ^
  329 |   });
  330 |   });
  331 |

  at Object.<anonymous> (src/server/sse.test.ts:328:27)

Test Suites: 1 failed, 31 passed, 32 total
Tests: 1 failed, 538 passed, 539 total
Snapshots: 0 total
Time: 5.98 s, estimated 7 s
Ran all test suites.