• Choose a category
• All
• Classic-Fiction

By Root 5531 0

incoming requests for an endpoint named hello.axd Note that the URL hello.axd doesn’t have to be a physical resource on the server; it’s simply a public resource identifier. The type attribute references the class and assembly that contain the handler. Its canonical format is type[,assembly]. You omit the assembly information if the component is defined in the App_Code or other reserved folders.

Important

As noted in Chapter 3, you usually don’t need both forms of an HTTP handler declaration in and . You need the former only if your application runs under IIS 6 (Windows Server 2003) or if it runs under IIS 7.x but is configured in classic mode. You need the latter only if your application runs under IIS 7.x in integrated mode. If you have both sections, you enable yourself to use a single web.config file for two distinct deployment scenarios. In this case, the element is key because it prevents IIS 7.x from strictly parsing the content of the configuration file. Furthermore, as discussed in Chapter 3, the and sections help in testing handlers and modules within Visual Studio if you’re using the embedded ASP.NET Development Server (also known as, Cassini).

If you invoke the hello.axd URL, you obtain the results shown in Figure 4-1.

Figure 4-1. sample HTTP handler that answers requests for hello.axd.

The technique discussed here is the quickest and simplest way of putting an HTTP handler to work, but there is more to know about the registration of HTTP handlers and there are many more options to take advantage of.

Note

It’s more common to use the ASHX extension for a handler mapping. The AXD extension is generally reserved for resource handlers that inject embedded content such as images, scripts, and so forth.

Registering the Handler

An HTTP handler is a class and must be compiled to an assembly before you can use it. The assembly must be deployed to the Bin directory of the application. If you plan to make this handler available to all applications, you can copy it to the global assembly cache (GAC). The next step is registering the handler with an individual application or with all the applications running on the Web server.

You already saw the script you need to register an HTTP handler. Table 4-2 expands a bit more on the attributes you can set up.

Table 4-2. Attributes Required to Register an HTTP Handler in

Attribute

Description

path

A wildcard string, or a single URL, that indicates the resources the handler will work on—for example, *. aspx.

type

Specifies a comma-separated class/assembly combination. ASP.NET searches for the assembly DLL first in the application’s private Bin directory and then in the system global assembly cache.

validate

If this attribute is set to false, ASP.NET loads the assembly with the handler on demand. The default value is true.

verb

Indicates the list of the supported HTTP verbs—for example, GET, PUT, and POST. The wildcard character (*) is an acceptable value and denotes all verbs.

All attributes except for validate are mandatory. When validate is set to false, ASP.NET delays as much as possible loading the assembly with the HTTP handler. In other words, the assembly will be loaded only when a request for it arrives. ASP.NET will not try to preload the assembly, thus catching earlier any errors or problems with it.

Additional attributes are available if you register the handler in . They are listed in Table 4-3.

Table 4-3. Attributes Required to Register an HTTP Handler in

Attribute

Description

allowPathInfo

If this attribute is set to true, the handler processes full path information in the URL or just the last section. It is set to false by default.

modules

Indicates the list of HTTP modules (comma-separated list of names) that are enabled to intercept requests for the current handler. The standard list contains only the ManagedPipelineHandler module.

name

Unique name of the handler.

path

A wildcard