{"id":3002,"date":"2025-12-08T18:12:12","date_gmt":"2025-12-08T18:12:12","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/12\/08\/net-10-networking-improvements\/"},"modified":"2025-12-08T18:12:12","modified_gmt":"2025-12-08T18:12:12","slug":"net-10-networking-improvements","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/12\/08\/net-10-networking-improvements\/","title":{"rendered":".NET 10 Networking Improvements"},"content":{"rendered":"

As with every release<\/a>, we publish a blog post about the new and interesting changes and additions in .NET networking space. This time, we are writing about HTTP<\/a> improvements, new web sockets<\/a> APIs, security<\/a> changes and many distinct additions in networking primitives<\/a>.<\/p>\n

HTTP<\/h2>\n

The following section introduces improvements and additions in HTTP space. Among them are a performance optimization in WinHttpHandler<\/code>, a new HTTP verb and small addition in cookies.<\/p>\n

WinHttpHandler<\/h3>\n

One of the performance improvements in .NET 10 is an optimization of server certificate validation in WinHttpHandler<\/code><\/a>. Normally, the validation is left to the native WinHTTP<\/em><\/a> implementation, which is expected to do the right thing. But sometimes, user code needs more control over the process and WinHttpHandler<\/code> offers ServerCertificateValidationCallback<\/code><\/a> for exactly that reason. Once the user code registers the callback, WinHttpHandler<\/code> skips the internal WinHTTP<\/em> validation. Unfortunately, there\u2019s no exact event raised by the native WinHTTP<\/em> that would correspond to connection establishment and would also provide the server certificate for validation. As a result, the managed layer within WinHttpHandler<\/code> is forced to invoke the custom ServerCertificateValidationCallback<\/code> on each and every request. To avoid this, a cache of already validated certificates by server IP address was put in place. Every time a new request is being sent, WinHttpHandler<\/code> skips building the whole certificate chain and invoking the custom callback if the certificate was previously validated. On top of that, each new connection clears up the cached certificate for that particular server IP to re-validate on connection recreation. To stay prudent from a security perspective, this feature (dotnet\/runtime#111791<\/a>) is opt-in and hidden behind an AppContext<\/code><\/a> switch:<\/p>\n

AppContext.SetSwitch(\"System.Net.Http.UseWinHttpCertificateCaching\", true);<\/code><\/pre>\n
The following example illustrates the effect of the switch:<\/p>\n
using System.Net.Security;\r\n\r\nAppContext.SetSwitch(\"System.Net.Http.UseWinHttpCertificateCaching\", true);\r\n\r\nusing var client = new HttpClient(new WinHttpHandler()\r\n{\r\n    ServerCertificateValidationCallback = static (req, cert, chain, errors) =>\r\n    {\r\n        Console.WriteLine(\"Server certificate validation invoked\");\r\n        return errors == SslPolicyErrors.None;\r\n    }\r\n});\r\n\r\nConsole.WriteLine((await client.GetAsync(\"https:\/\/github.com\")).StatusCode);\r\nConsole.WriteLine((await client.GetAsync(\"https:\/\/github.com\")).StatusCode);\r\nConsole.WriteLine((await client.GetAsync(\"https:\/\/github.com\")).StatusCode);<\/code><\/pre>\n
The callback is invoked only once, with output like the following:<\/p>\n
Server certificate validation invoked\r\nOK\r\nOK\r\nOK<\/code><\/pre>\n
Whereas without the switch, the callback is invoked with each request:<\/p>\n
Server certificate validation invoked\r\nOK\r\nServer certificate validation invoked\r\nOK\r\nServer certificate validation invoked\r\nOK<\/code><\/pre>\n
The following graph shows the cumulative time saved with the certificate caching per increasing number of requests:
\n\"Cumulative<\/p>\n
QUERY<\/h3>\n
Another addition is a new HTTP verb QUERY<\/code>. The purpose of the verb is to allow sending details for the query in the request body while still using a safe, idempotent request. In other words, being able to execute multiple times without affecting server data. One of the use cases is when the details of the query might not fit into URI length limits and using body in GET<\/code> request is not supported by the server. The verb is still in process of standardization in The HTTP QUERY Method<\/a> proposal. For that reason, we have decided to postpone the full implementation of the helper methods in dotnet\/runtime#113522<\/a> until the RFC is published. And we only added the string constant in dotnet\/runtime#114489<\/a>, which can be used this way:<\/p>\n
using var client = new HttpClient();\r\nvar response = await client.SendAsync(new HttpRequestMessage(HttpMethod.Query, \"https:\/\/api.example.com\/resource\"));<\/code><\/pre>\n
Cookies<\/h3>\n
A very small change was requested: making the CookieException<\/code><\/a> constructor public in dotnet\/runtime#95965<\/a>. The change was made by a community contributor @deeprobin<\/a> in dotnet\/runtime#109026<\/a>. CookieException<\/code> can now be manually thrown to avoid unexpected visits from Cookie Monster<\/em>:<\/p>\n
throw new CookieException(\"\ud83c\udf6a\");<\/code><\/pre>\n
WebSockets<\/h2>\n
Working with raw WebSocket<\/code> APIs means dealing with low-level details\u2014buffering, framing, encoding, and custom wrappers to integrate with streams or channels. This complexity makes building transport layers and streaming protocols harder.<\/p>\n
.NET 10 introduces WebSocketStream<\/code><\/a>, a stream-based abstraction over WebSockets that makes reading, writing, and parsing data for text and binary protocols much simpler.<\/p>\n
Key advantages:<\/p>\n