Asynchronously Reading and Writing HTTP Requests and Responses
ASP.NET 4 introduced the ability to read an HTTP
request entity as a stream using the
HttpRequest.GetBufferlessInputStream
method. This method provided streaming access to the request entity. However, it
executed synchronously, which tied up a thread for the duration of a request.
ASP.NET 4.5 supports the ability to read streams asynchronously
on an HTTP request entity, and the ability to flush asynchronously. ASP.NET 4.5
also gives you the ability to double-buffer an HTTP request entity, which
provides easier integration with downstream HTTP handlers such as .aspx page handlers and ASP.NET MVC controllers.
Improvements to HttpRequest handling
The Stream reference returned
by ASP.NET 4.5 from
HttpRequest.GetBufferlessInputStream
supports both synchronous and asynchronous read methods. The
Stream object returned from
GetBufferlessInputStream now implements both the BeginRead and EndRead
methods. The asynchronous
Stream methods let
you asynchronously read the request entity in chunks, while ASP.NET releases
the current thread between each iteration of an asynchronous read loop.
ASP.NET 4.5 has also added a companion method for
reading the request entity in a buffered way:
HttpRequest.GetBufferedInputStream.
This new overload works like
GetBufferlessInputStream,
supporting both synchronous and asynchronous reads. However, as it reads,
GetBufferedInputStream also copies the entity
bytes into ASP.NET internal buffers so that downstream modules and handlers can
still access the request entity. For example, if some upstream code in the
pipeline has already read the request entity using
GetBufferedInputStream,
you can still use
HttpRequest.Form or
HttpRequest.Files.
Asynchronously flushing a response
Sending responses to an HTTP client can take considerable time
when the client is far away or has a low-bandwidth connection. Normally ASP.NET
buffers the response bytes as they are created by an application. ASP.NET then
performs a single send operation of the accrued buffers at the very end of
request processing.
If the buffered response is large (for example, streaming a
large file to a client), you must periodically call
HttpResponse.Flush to send buffered output to the
client and keep memory usage under control. However, because
Flush is a synchronous call, iteratively calling
Flush still consumes a thread for the duration of
potentially long-running requests.
ASP.NET 4.5 adds support for performing flushes
asynchronously using the
BeginFlush and
EndFlush methods of the
HttpResponse class. Using these methods, you can create
asynchronous modules and asynchronous handlers that incrementally send data to
a client without tying up operating-system threads. In between
BeginFlush and
EndFlush
calls, ASP.NET releases the current thread. This substantially reduces the
total number of active threads that are needed in order to support long-running
HTTP downloads.
More features:
Support for await and Task-Based
Asynchronous Modules and Handlers
New ASP.NET Request Validation Features
By default, ASP.NET performs request validation — it examines
requests to look for markup or script in fields, headers, cookies, and so on.
If any is detected, ASP.NET throws an exception. This acts as a first line of
defense against potential cross-site scripting attacks.
ASP.NET 4.5 makes it easy to selectively read
unvalidated request data. ASP.NET 4.5 also integrates the popular AntiXSS
library, which was formerly an external library.
Developers have frequently asked for the ability to
selectively turn off request validation for their applications. For example, if
your application is forum software, you might want to allow users to submit
HTML-formatted forum posts and comments, but still make sure that request
validation is checking everything else.
ASP.NET 4.5 introduces two features that make it easy for
you to selectively work with unvalidated input: deferred ("lazy") request
validation and access to unvalidated request data.
Deferred ("lazy") request validation
In ASP.NET 4.5, by default all request data is subject
to request validation. However, you can configure the application to defer request
validation until you actually access request data. (This is sometimes referred
to as lazy request
validation, based on terms like lazy
loading for certain data scenarios.) You can configure the
application to use deferred validation in the Web.config
file by setting the
requestValidationMode
attribute to 4.5 in the
httpRUntime element, as in the following example:
<httpRuntime requestValidationMode="4.5" ... />
AntiXSS Library
Due to the popularity of the Microsoft AntiXSS Library, ASP.NET 4.5
now incorporates core encoding routines from version 4.0 of that library.
To do this, add the following attribute to the Web.config file:
<httpRuntime ...
encoderType="System.Web.Security.AntiXss.AntiXssEncoder,
System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
When the
encoderType attribute
is set to use the
AntiXssEncoder type, all
output encoding in ASP.NET automatically uses the new encoding routines.
To enable GC memory tuning, add the following setting to the
Windows\Microsoft.NET\Framework \v4.0.30319\aspnet.config
file:
<configuration>
<!-- ... -->
<runtime>
<performanceScenario value="HighDensityWebHosting" />
