5. Application Initialization
Nothing frustrates users more than trying to open a website in their
web browser and then waiting for the site to respond. With previous
versions of IIS, the delay that occurred when a web application was
first accessed was because the application needed to be loaded into
memory before IIS could process the user’s request and return a
response. With complex Microsoft ASP.NET web applications often needing
to perform lengthy startup tasks, such as generating and caching
content, such delays could sometimes reach up to a minute or more in
some cases.
Such delays are now a thing of the past with the new Application
Initialization feature of IIS 8, which lets you configure IIS to spin
up web applications so they are ready to respond to the first request
received. Application
pools can be prestarted instead of waiting for a first request, and
application are initialized when their worker processes start.
Administrators can decide which applications should be preloaded on the
server.
In addition, IIS 8 can be configured to return a static “splash page”
or other static content while an application is being initialized so
the user feels the website being accessed is responding instead of
failing to respond. This functionality can be combined with the URL Rewrite module to create more complex types of pregenerated static content.
Application Initialization can be configured at two levels:
-
Machine-wide, in the ApplicationHost.config file for the server
-
Per application, in the Web.config file for the application
The Application Initialization role service of the Web Server role
must also be added to the server to use this feature.
Identifying “fake” requests used by Application Initialization
The Application Initialization feature introduces the concept of a warm-up
period to IIS. When this feature is configured, the set of URLs
specified by the application developer will be sent a “fake” request as
part of warming up the application. Once all the fake requests return, the application is considered initialized, and the warm-up period ends.
Depending on your application, you may decide to handle these fake
requests differently than normal requests coming from the wire. If you
choose to do this, using the URL Rewrite module allows you to look at the request headers and identify the fake requests.
Identifying fake requests is easy if you know what to look for. A
fake request sent to a URL as part of application-level initialization
has the following properties.
In addition to application-level initialization, the Application
Initialization feature also allows server administrators to “preload” important applications so that they will be initialized as soon as the worker process starts. Preload is also done using a fake request to the root of the application. The Preload fake request has the following properties:
You may also want to perform special handling for normal requests
that are received during the warm-up period. All normal requests
received during warm-up have the APP_WARMING_UP server variable set, which you can use to identify these requests and handle them as desired.
6. Dynamic IP Address Restrictions
When a web server receives unwanted activity from malicious clients,
it can prevent legitimate users from accessing websites hosted by the
server. One way of dealing with such situations in previous versions of
IIS was to use static IP filtering to block requests from specific clients. Static filtering had two limitations, however:
-
It required that you discover the IP address of the offending client and then manually configure IIS to block that address.
-
There was no choice as to what action IIS would take when it blocked
the client—an HTTP 403.6 status message was always returned to the
offending client.
In IIS 8, however, blocking malicious IP addresses is now much simpler. Dynamic IP Address Restrictions now provides three kinds of filtering to deal with undesirable request traffic:
-
Dynamic
IP address filtering lets you configure your server to block access for
any IP address that exceeds a specified number of concurrent requests
or exceeds a specified number of requests within a given period of time.
-
You can now configure how IIS responds when it blocks an IP address; for example, by aborting the request instead of returning HTTP 403.6 responses to the client.
-
IP addresses can be blocked not only by client address, but also by addresses received in the X-Forwarded-For HTTP header used in proxy mode.
Configuring dynamic IP address filtering
To configure dynamic IP address filtering for your server, website,
or folder path, select the corresponding IP Address And Domain
Restrictions node in IIS Manager. This opens the Dynamic IP Restriction Settings dialog box shown in Figure 4,
which lets you deny IP addresses based on the number of concurrent
requests and/or the number of requests received over a specified period
of time.
Once dynamic IP address filtering has been configured, you can
configure how IIS responds to clients whose requests are dynamically
filtered. To do this, select the appropriate IP Address And Domain
Restrictions node in IIS Manager and click Edit Feature Settings in the
Actions pane. Doing this opens the Edit IP And Domain Restriction
Settings dialog box shown in Figure 5,
which lets you specify the type of response and whether to enforce such
responses when the incoming request passes through a proxy, such as a
firewall or load balancer, that changes the source IP address of the
request.
