Memory optimization for a large HttpWebRequest POST or PUT based on .NET framework 4.5
This article helps you resolve the problem that occurs when you use the
HttpWebRequest class to send lots of data for an HTTP POST or PUT request.
Original product version: .NET Framework 4.5
Original KB number: 2855735
When you use the
HttpWebRequest class to send lots of data for an HTTP POST or PUT request, the request may fail on a computer that is running the Microsoft .NET Framework. Additionally, you may receive an out-of-memory exception.
You may notice that the application that uses the
HttpWebRequest class consumes lots of memories. When you use Performance Monitor to monitor the application that uses the
HttpWebRequest class, the Private Bytes count will continue to increase as data is sent.
This issue occurs because the .NET Framework buffers the outgoing data by default when you use the
HttpWebRequest class. A POST or PUT request fails when you use the HttpWebRequest class to send lots of data documents the original issue.
To work around this issue, set the
HttpWebRequest.AllowWriteStreamBuffering property to false. By doing this, outgoing data (entity body) for the POST or the PUT request will not be buffered in memory.
In versions of .NET Framework earlier than 4.5, setting
HttpWebRequest.AllowWriteStreamBuffering property to false would sometimes result in errors when uploading data to authenticated endpoints. For example, you might encounter a
System.Net.WebException with the message This request requires buffering data to succeed. However, on deeper investigation the response associated with the exception actually indicates a status code of
System.Net.HttpStatusCode.Unauthorized (401). A POST or PUT request fails when you use the HttpWebRequest class to send lots of data documents a workaround of pre-authentication and KeepAlive connection to handle 401 response.
Unlike .NET Framework 1.1, 2.0, 3.0, 3.5 and 4.0, .NET Framework 4.5 adds new design functionality for the
HttpWebRequest.AllowWriteStreamBuffering property. The new functionality can handle the authentication scenario directly as long as the
Expect100Continue feature is enabled. The default
ServicePointManager.Expect100Continue value is true.