modelcontextprotocol/csharp-sdk
Watch
1
0
Fork
You've already forked csharp-sdk
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2

V2 Edit pass (#1728)

Browse source
This commit is contained in:
Genevieve Warren 2026-07-23 23:09:51 -07:00 • committed by GitHub
commit b283596df1
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 263 additions and 251 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/concepts/httpcontext/httpcontext.md
View file

@ -34,11 +34,11 @@ and the `GetHttpHeaders` method accessing the current [HttpContext] to retrieve
When using the legacy SSE transport, be aware that the `HttpContext` returned by `IHttpContextAccessor` references the long-lived SSE connection request — not the individual `POST` request that triggered the tool call. This means:
- The `HttpContext.User` may contain stale claims if the client's token was refreshed after the SSE connection was established.
- The `HttpContext.User` might contain stale claims if the client's token was refreshed after the SSE connection was established.
- Request headers, query strings, and other per-request metadata will reflect the initial SSE connection, not the current operation.
The Streamable HTTP transport does not have this issue because each tool call is its own HTTP request, so `IHttpContextAccessor.HttpContext` always reflects the current request. In [stateless](xref:stateless) mode, this is guaranteed since every request creates a fresh server context.
<!-- mlc-disable-next-line -->
> [!NOTE]
> The server validates that the user identity has not changed between the session-initiating request and subsequent requests (using the `sub`, `NameIdentifier`, or `UPN` claim). If the user identity changes, the request is rejected with `403 Forbidden`. However, other claims (roles, permissions, custom claims) are not re-validated and may become stale over the lifetime of a session.
> The server validates that the user identity has not changed between the session-initiating request and subsequent requests (using the `sub`, `NameIdentifier`, or `UPN` claim). If the user identity changes, the request is rejected with `403 Forbidden`. However, other claims (roles, permissions, custom claims) are not re-validated and might become stale over the lifetime of a session.