<configuration> |
<configuration> </configuration> |
The root element for all configuration files; it is required.
All
None
<appSettings> |
<appSettings> </appSettings> |
The <appSettings> element can be used to configure custom application settings as key/value pairs. These settings can later be retrieved at runtime using the AppSettings property of the ConfigurationSettings class, as shown in the example. This property is shared (static) and does not require the ConfigurationSettings class to be instantiated before accessing the property.
Any
None
The key/value pair to add.
The key to remove.
Clears all previously added key/value pairs.
The following web.config section sets an application level key/value pair:
<configuration> <appSettings> <add key="applicationConfigKey" value="bar"/> </appSettings> </configuration>
The following ASP.NET page retrieves the value set by the preceding code and also retrieves a value set at the machine.config level:
<%@ Page Language="VB" %> <html> <head> <script runat="server"> Sub Page_Load( ) Message1.Text &= _ ConfigurationSettings.AppSettings("machineConfigKey") Message2.Text &= _ ConfigurationSettings.AppSettings("applicationConfigKey") End Sub </script> </head> <body> <asp:label id="Message1" runat="server">Machine.Config setting: </ asp:label> <br/> <asp:label id="Message2" runat="server">Web.Config setting: </ asp:label> </body> </html>
As shown in the example, the <appSettings> element can be used separately from the <system.web> element and its children.
For security reasons, use caution when deciding what kinds of data to store using the <appSettings> element. Remember that while the ASP.NET runtime is set up to prevent an application's web.config file from being requested or read, this file could still be vulnerable if the security of the web server were breached in some other way. Thus, you should generally avoid storing sensitive information such as usernames and passwords, or connection strings containing usernames and passwords, in the web.config file. A better, although still moderately vulnerable, alternative is to store this information at the machine.config level, since this file is not within the web space of the application and is not as vulnerable to compromise through attacks on IIS. However, remember that this information will be available to any application on the machine.
<system.web> |
<system.web> </system.web> |
Container element for all elements used in web.config files.
All
None
<authentication>, <authorization>, <browserCaps>, <clientTarget>, <compilation>, <customErrors>, <globalization>, <httpHandlers>, <httpModules>, <httpRuntime>, <identity>, <iisFilter>, <machineKey>, <pages>, <processModel>, <securityPolicy>, <sessionState>, <trace>, <trust>, <webServices>
This element is required in order to use any of its child elements.
<authentication> |
<authentication> </authentication> |
Provides attributes and contains child elements used to configure authentication options in ASP.NET.
Machine, Application
Determines the type of authentication that will be used by ASP.NET. Valid values are as follows:
Uses credentials provided by IIS authentication methods (Basic, Digest, Integrated Windows Authentication, or Certificates) to authenticate user requests. Requests can then be permitted or denied based on settings contained within the <authorization> element, using the authenticated username (or an associated group/role name) to allow or deny the request. This is the default authentication mode defined in machine.config.
Provides an infrastructure for performing custom authentication in situations when Windows authentication is not possible. When Forms authentication is enabled, users who have not logged in are automatically redirected to a login URL provided as an attribute of the <forms> element. Once logged in, a cookie is sent as an authentication token. Users can be authenticated against any credentials database the developer choosesfrom Active Directory to a custom credentials database. This mode requires the inclusion of the <forms> child element.
Takes advantage of Microsoft's Passport authentication service. This mode requires inclusion of the <passport> child element.
Specifies that no authentication be performed at the ASP.NET level. Requests can still be authenticated at the IIS level using one of the IIS authentication modes in combination with NTFS access control lists (ACLs).
<forms>, <passport>
The example configures the pages within the scope of the configuration file to use ASP.NET forms-based authentication:
<configuration> <system.web> <authentication mode="Forms"> <forms name="myAuthCookie" loginUrl="login.aspx" protection="All" timeout="30" path="/" /> </authentication> </system.web> </configuration>
The <location> element can be used to configure authentication at the machine level, if desired, and its allowOverride attribute can be used to prevent overriding these settings in individual applications.
Authentication can be a fairly involved topic. For more information on the various ASP.NET authentication methods and how they relate to IIS authentication, please see Chapter 9.
<forms> |
<forms loginUrl=String name=String path=String protection="All|None|Encryption|Validation" requireSsl=boolean slidingExpiration=boolean timeout=Integer> </forms> |
Provides attributes and one child element (<credentials>) to configure ASP.NET to use forms-based authentication.
Machine, Application
Specifies the name of the authentication cookie. If this attribute is omitted, the value defaults to .ASPXAUTH. When running multiple applications that use forms-based authentication on the same server, it's usually a good idea to give each application its own authentication cookie nameto minimize the risk of authenticated users from one application being treated as authenticated in others.
Specifies the redirect URL for users who do not have a valid authentication cookie. If a user with no authentication cookie requests a page in the application, they will be redirected to this URL to log in. The login page can then redirect the user back to the originally requested page. If this attribute is omitted, the value defaults to login.aspx.
Specifies the type of protection used to prevent the authentication cookie from being modified during transit. Valid values are as follows:
Cookies are both encrypted (using triple DES encryption, if available) and subjected to data validation. Data validation is performed based on the settings of the <machineKey> element. All is the default value and is the recommended setting for securing the authentication cookie.
Cookies are only encrypted. This reduces overhead associated with cookie protection, but may leave cookies vulnerable to plain-text attacks.
Neither encryption nor validation is enabled for cookie protection. This reduces overhead when using forms-based authentication, but provides no protection of the authentication cookie. This attribute is not recommended.
A validation key is concatenated with cookie data. This key is checked to ensure that cookie data has not been altered in transit.
When set to True, prevents compliant browsers from sending the authentication cookie unless the connection is using SSL encryption. The default value is False. This attribute is only supported in Version 1.1 of ASP.NET.
When set to True, each request within the same session will reset the timeout value for the authentication cookie. The default value is True. This attribute is supported only in Version 1.1 of ASP.NET.
Specifies the amount of time, in minutes, before the authentication cookie expires. This is a sliding value, which is reset when a request is received after more than half of the timeout period has elapsed. Note that this attribute does not apply to persistent cookies. The default value is 30.
Specifies the path for the authentication cookie. Because many browsers treat the path in a case-sensitive manner, the default is set to the backslash (\) character.
<credentials>
See the example for the <authentication> element.
Forms-based authentication is only effective when used in conjunction with the <authorization> element to deny anonymous users access to pages within the application.
It's a good idea to use SSL encryption to protect the forms authentication credentials and cookie to prevent the possibility of these credentials being hijacked. If you can't (or don't want to) use SSL, you should at least reduce the default timeout value to lessen the likelihood of someone capturing and impersonating the authentication cookie.
<credentials> |
<credentials passwordFormat="Clear|SHA1|MD5"> </credentials> |
Allows you to store one or more sets of credentials in the application (or machine) configuration file for later use in authenticating requests. The child <user> element is used to store the actual credentials.
Machine, Application
Specifies the format in which passwords will be stored (and compared). Valid options are Clear, SHA1, and MD5.
<user>
The example shows the <credentials> element, which is used to store two user accounts to authenticate against:
<credentials passwordFormat = "SHA1"> <user name="foo" password="794ED3D18464BAFF93F8DED1CFD00D9A2D9FE316"/> <user name="bar" password="B7CDD2A2B0F05E6948E5CEED22FA9A38EB28DEC8"/> </credentials>
Once you've stored the credentials, you can authenticate against them by calling the static (shared) Authenticate method of the FormsAuthentication helper class. You can use the static (shared) HashPasswordForStoringInConfigFile method of FormsAuthentication to create an MD5 or SHA1 hash of the password for storing in the <user> element. When using the <credentials> element to store credentials, you should always hash passwords, since storing them in readable text presents a potential security risk. Although theoretically, no one should be able to read the configuration file, a server misconfiguration or security vulnerability could conceivably expose this file.
<user> |
Stores the username and password for each user defined in the <credentials> element.
Machine, Application
The username to be authenticated against.
The password to be authenticated against.
None
See the example for the <credentials> element.
You should always use the HashPasswordForStoringInConfigFile method to hash passwords stored in the password attribute. A utility page that creates SHA1 or MD5 hashes of plain text passwords is provided in the examples for Chapter 9.
<passport> |
<passport redirectUrl=Url /> |
This optional element configures an internal URL to which unauthenticated requests will be redirected when using Microsoft's Passport authentication provider. This element should be used only when the <authentication> element's mode attribute is set to Passport.
Machine, Application
A URL in the application to which requests lacking a Passport authentication token are redirected.
None
This example shows a web.config file that configures an application for Passport authentication:
<configuration> <system.web> <authentication mode="Passport"> <passport redirectUrl="Login.aspx"/> </authentication> </system.web> </configuration>
For more information on configuring Passport authentication, see the Passport SDK documentation, which is available from http://www.passport.com.
<authorization> |
Provides two child elements, <allow> and <deny>, that allow you to configure the users, roles, or HTTP verbs that can be used to access application resources.
Any
None
<allow>, <deny>
The example allows users Mary and John to access application resources using any HTTP verb, while denying POST access to nonauthenticated users:
<configuration> <system.web> <authorization> <allow users="Mary, John" /> <deny users="?" verbs="POST" /> </authorization> </system.web> </configuration>
The type of authorization implemented by the <authorization> element is referred to as URL authorization. You can read more about URL authorization in Chapter 9.
You can specify authorization settings for a specific file or directory in your application that differs from the defaults configured in the root web.config file for the application in either of two ways:
By adding an <authorization> element to the web.config file of the desired child directory, as shown in the example.
By using a <location> tag in the root web.config file and setting its path attribute to the desired path, as follows:
<configuration> <location path="files"> <system.web> <authorization> <deny users="?" /> </authorization> </system.web> </location> <system.web> <!--other configuration settings --> </system.web> </configuration>
<allow> |
Specifies users, roles, and/or HTTP verbs to be authorized for the application.
Any
A comma-delimited list of authorized usernames.
A comma-delimited list of authorized roles (NT groups).
A comma-delimited list of authorized HTTP verbs (GET, HEAD, POST, or DEBUG).
None
See the example for the <authorization> element.
You can use two wildcards to specify special groups of users:
When used for the value of the user attribute, allows access for all users. This is the default configuration setting, as defined in machine.config.
When used for the value of the user attribute, allows access to anonymous users. This wildcard is more commonly used with the <deny> element.
<deny> |
Specifies users, roles, and/or HTTP verbs to be denied authorization for the application.
Any
A comma-delimited list of authorized usernames.
A comma-delimited list of authorized roles (NT groups).
A comma-delimited list of authorized HTTP verbs (GET, HEAD, POST, or DEBUG).
None
See the example for the <authorization> element.
The same wildcards used by the <allow> element also apply to the deny element. To deny access to anonymous (non-authenticated) users, set the value of the users attribute of the <deny> element to ?.
<browserCaps> |
<browserCaps> <result type=className /> <use var=serverVarName /> property1=value property2=value propertyN=value <filter match=string> property1=value property2=value propertyN=value </filter> <filter match=string> <filter match=string with=expressionToSearch> property1=value property2=value propertyN=value </filter> </filter> <filter> <case match=string> property1=value property2=value propertyN=value </case> <case match=string> property1=value property2=value propertyN=value </case> </filter> </browserCaps> |
Controls the configuration of the browser capabilities component returned by the Response.Browser property. The property/value pairs under the <use> element configure the default values of the browser capabilities component properties; the property/value pairs in the <filter> elements update these properties based on a match between the string value specified for the match attribute of the <case> element and the value of the var attribute of the <use> element (which is typically set to HTTP_USER_AGENT).
Any
None
<result>, <use>, <filter>
The machine.config configuration file contains the default settings for the <browserCaps> element. The default settings provide the best example for modifying or updating this element.
The primary purpose of this configuration element and its children is to allow the addition of new browser types and to update the capabilities of these browsers. Thus, when a page calls the browser capabilities component, it will receive accurate information about the capabilities of the browser used for the current request.
<result> |
<result type=className /> |
Specifies the class.
Any
The class name, and optionally, version, culture, and key information that specifies the class that will contain the results of the browser capabilities analysis. This class must derive from HttpCapabilitiesBase. The default (set in machine.config) is System.Web.HttpBrowserCapabilities.
None
The default type of System.Web.HttpBrowserCapabilities is fine in most cases. If you want to add additional properties beyond those defined by the HttpBrowserCapabilities class, you can create your own class (derived from HttpCapabilitiesBase or HttpBrowserCapabilities) and use the <result> element to substitute it.
<use> |
<use var=serverVariableName as=aliasName /> |
Sets the name of the server variable to use when evaluating browser capabilities.
Any
The name of the server variable to use. The default is HTTP_USER_AGENT.
The string containing a name by which the server variable can be referenced in <case> elements and regular expressions.
None
The <use> element is followed by property/value pairs that specify the default properties for the browser capabilities component if no match is found with a <filter> element's match attribute (or that of its child <case> element). This usage is demonstrated in the entry for the <browserCaps> element.
<filter> |
<filter match=string> property1=value property2=value propertyN=value </filter> <filter match=string> <filter match=string with=expressionToSearch> property1=value property2=value propertyN=value </filter> </filter> <filter> <case match=string> property1=value property2=value propertyN=value </case> <case match=string> property1=value property2=value propertyN=value </case> </filter> |
Specifies a regular expression pattern to search for in the server variable given in the <use> element (or optionally, another expression). Multiple <filter> elements can be contained in the <browserCaps> element; likewise, each <filter> element can contain <case> elements or other <filter> elements. All property assignments for matching <filter> elements will be executed, regardless of their order.
Any
The pattern to match. Uses .NET Framework regular expression syntax. This attribute is optional. If omitted, all requests will be assumed to match and any property/value assignments contained within the <filter> element will be executed.
The regular expression or string to find. This attribute is optional. If omitted, the server variable specified in the <use> element will be searched.
<case>
The fact that <filter> elements can be nested makes them very flexible in terms of locating subsets of information. For example, the default <browserCaps> element in machine.config uses nested <filter> elements to locate both the major and minor browser versions contained in the HTTP_USER_AGENT server variable so that it can assign specific properties that vary among minor versions (i.e., the x in 4.x) of a browser.
<case> |
<case match=string> property1=value property2=value propertyN=value </case> |
Specifies one of a group of exclusive matching cases for which property assignments will be executed. Only the first matching <case> element within a given <filter> element will be executed. The rest will be ignored.
Any
The pattern to match. Uses the .NET Framework regular expression syntax. This attribute is optional. If omitted, all requests will be assumed to match, and any property/value assignments contained within the <filter> element will be executed.
The regular expression or string to find. This attribute is optional. If omitted, the server variable specified in the <use> element will be searched.
None
This element is useful in situations when you only want a single match. For example, the default <browserCaps> configuration in machine.config uses the <case> element to assign the platform, win16, and win32 attributes.
<clientTarget> |
<clientTarget> <add alias=aliasName userAgent=userAgentString /> <remove alias=aliasName /> <clear /> </clientTarget> |
Assigns aliases for specified browser user agent strings to be used by ASP.NET Server Controls in deciding what type of content to render.
Any
None
Adds an alias with the name specified by the alias attribute for the User Agent string specified by the userAgent attribute.
Removes a previously configured alias with the name specified by the alias attribute.
Clears all previously configured aliases.
This example comes from the default <clientTarget> element:
<clientTarget> <add alias="ie5" userAgent="Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)" /> <add alias="ie4" userAgent="Mozilla/4.0 (compatible; MSIE 4.0; Windows NT 4.0)" /> <add alias="uplevel" userAgent="Mozilla/4.0 (compatible; MSIE 4.0; Windows NT 4.0)" /> <add alias="downlevel" userAgent="Unknown" /> </clientTarget>
This element is used primarily by the built-in ASP.NET Server Controls. Thus, you should avoid making changes to the existing aliases to avoid preventing these controls from rendering uplevel content.
<compilation> |
<compilation batch=boolean batchTimeout=numSeconds debug=boolean defaultLanguage=languageAlias explicit=boolean maxBatchSize=maxPages maxBatchGeneratedFileSize=maxSize numRecompilesBeforeAppRestart=numRecompiles strict=boolean tempDirectory=dirName > <compilers> <compiler language=languageAlias extension=fileExt type=typeName warningLevel=number compilerOptions=optionString /> </compilers> <assemblies> <add assembly=assemblyName /> <remove assembly=assemblyName /> <clear /> </assemblies> </compilation> |
Provides attributes and child elements for configuring the compilation options of ASP.NET applications. All attributes are optional.
Any
Specifies whether ASP.NET should attempt to batch compile all pages in the application when the first request for a page is made. The default is True.
Specifies the amount of time, in seconds, that the compiler will spend attempting to batch compile pages in the application. If the timeout is exceeded, pages will be compiled as they are requested for the first time. The default is 15.
Specifies whether pages will be compiled with debug symbols. The default is False.
Specifies the language compiler that will be used to compile inline code in ASP.NET pages for which no language is specified. The default is VB (Visual Basic .NET).
Specifies whether the Visual Basic .NET Option Explicit compiler option is enabled. The default is True.
Specifies the maximum number of classes generated during batch compilation. The default is 1000.
Specifies the maximum combined size in KB of generated source files created during batch compilation. The default is 3000.
Specifies the number of recompiles before the appDomain containing the application is cycled (a new appDomain is created and the old one is torn down). The default is 15.
Specifies whether the Visual Basic .NET Option Strict compiler option (which disallows implicit narrowing conversions) is enabled. The default is False.
Specifies the directory in which temporary files from dynamically compiled code for the application will be stored. The default is %windir%\Microsoft.NET\Framework\%version%\Temporary ASP.NET Files.
<assemblies>, <compilers>
The example enables the Visual Basic .NET Option Strict compiler option and disables batch compilation:
<configuration> <system.web> <compilation batch="false" strict="true"> </compilation> </system.web> </configuration>
Make sure you understand the impact of changes to this element before making modifications. For example, setting the debug attribute to True will have a significant negative impact on performance. While setting the strict attribute to True will reduce the likelihood of bugs from implicit data type conversion, it could also increase the number of compiler errors you get while developing your code.
<assemblies> |
<assemblies> <add assembly=assemblyInfo /> <remove assembly=assemblyInfo /> <clear /> </assemblies> |
Adds or removes assemblies to be referenced and linked during dynamic compilation of ASP.NET pages. By default, the mscorlib, System, System.Drawing, System.EnterpriseServices, System.Web, System.Data, System.Web.Services, and System.Xml assemblies are referenced during dynamic compilation, as are any assemblies located in the application directory's bin subdirectory.
Any
None
Adds an assembly specified by the assembly attribute to the list of assemblies to be linked during dynamic resource compilation.
Removes a previously configured assembly specified by the assembly attribute from the list of assemblies to be linked during dynamic resource compilation.
<clear>
Clears all previously configured assemblies.
This example shows the <add> element used by the Mobile Internet Toolkit to add the assembly System.Web.Mobile to the list of assemblies for dynamic compilation:
<assemblies> <add assembly="System.Web.Mobile, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" /> </assemblies>
The asterisk (*) wildcard is used with the <add> element to indicate that all assemblies in the application's private assembly cache (by default, the bin subdirectory of the application) should be added to the list of assemblies linked during dynamic compilation. This ensures that all members of these assemblies will be available to all the pages in your application automatically.
<compilers> |
<compilers> <compiler language=languageAlias extension=fileExt type=typeName warningLevel=number compilerOptions=optionString /> </compilers> |
Contains one or more <compiler> elements, each of which defines configuration options for a particular compiler to be used with ASP.NET.
Any
None
<compiler>
Thanks to the <compilers> and <compiler> elements, adding support for a new .NET language in ASP.NET is as simple as adding a new <compiler> element specifying the language aliases, the file extension for class files for the language, and the type information for the language compiler.
<compiler> |
<compiler language=languageAlias extension=fileExt type=typeName warningLevel=number compilerOptions=optionString /> |
Specifies configuration options for a given language.
Any
Specifies the name or names by which the language will be specified in the language attribute of the @ Page directive. Multiple names should be separated by semicolons. This attribute is required.
Specifies the extension(s) used by code-behind files for the specified language. Multiple entries should be separated by semicolons. This attribute is required.
Specifies the .NET type information for the class to be used to compile resources for the specified language. This attribute is required.
Specifies the compiler warning level for the language. This attribute is optional and may not be supported for all compilers.
Specifies a string containing valid compiler options to be passed to the compiler.
None
The <compilers> element in machine.config provides a good example of the use of this element. Review that configuration section to see how the Visual Basic .NET, C#, and JScript .NET compilers are configured.
<customErrors> |
<customErrors defaultRedirect=Url mode=mode > <error statusCode=httpStatusCode redirect=Url /> </customErrors> |
Specifies one or more pages to which users should be redirected if an unhandled exception is detected in an ASP.NET application. A default error page can be specified, as well as one or more error pages for specific HTTP error codes.
Any
Specifies the URL of the page to which all errors should be redirected when no specific error page is configured for the HTTP status code of the error. This attribute is optional.
Specifies the custom errors mode. Valid values are Off, On, and RemoteOnly. Off disables custom error handling, On enables custom error pages for both local and remote requests. RemoteOnly enables custom error pages for remote requests, while sending detailed error messages for local requests. This attribute is required.
<error>
The example configures a default page to be displayed to remote clients when an unhandled exception is encountered:
<configuration> <system.web> <customErrors defaultRedirect="Error.aspx" /> </system.web> </configuration>
If you set the mode attribute to RemoteOnly, you will only be able to see detailed error information from the local machine on which the pages are running. Remote requests will return the custom error page (if any) configured for the status code of the error that occurred.
If you want to see the debug information provided by ASP.NET when an error occurs, the mode attribute should be set to Off.
<error> |
<error statusCode=httpStatusCode redirect=Url /> |
Specifies a custom error page to handle redirections for a specific HTTP status code.
Any
Specifies the HTTP status code (such as 404 for a "Not Found" error) for the specified custom error page. This attribute is optional.
Specifies the URL of the page to which requests with a matching HTTP status code should be redirected. This attribute is optional.
None
The example configures a custom error page for 404 errors, and the default error page configured in the previous example:
<configuration> <system.web> <customErrors defaultRedirect="Error.aspx"> <error statusCode="404" redirect="My404ErrorPage.aspx"/> </customErrors> </system.web> </configuration>
While custom error pages provide a convenient way to prevent users from seeing raw error messages (and perhaps provide more helpful messages), they are not a substitute for proper exception handling. By the time an error reaches a custom error page, recovering from the error gracefully will be much more difficult, which can degrade the experience of your users.
<globalization> |
<globalization requestEncoding=encodingString responseEncoding=encodingString fileEncoding=encodingString culture=cultureString uiCulture=cultureString /> |
Provides attributes for configuring encoding and culture settings. These attributes are used as the basis for the expected encoding of requests, responses, and files for internationalization.
Any
Specifies the assumed encoding of incoming requests. This can be any valid encoding string and should match the responseEncoding attribute. The default is UTF-8. This attribute is optional.
Specifies the content encoding of responses. This can be any valid encoding string and should match the requestEncoding attribute. The default is UTF-8. This attribute is optional.
Specifies the encoding used to parse .aspx, .asmx, and .asax files. This attribute is optional.
Specifies the assumed culture for incoming requests. The value can be any valid culture string. This attribute is optional.
Specifies the culture for locale-specific resource searches. The value can be any valid culture string. This attribute is optional.
None
This example shows how the default <globalization> settings are configured in web.config:
<configuration> <system.web> <globalization requestEncoding="utf-8" responseEncoding="utf-8" /> </system.web> </configuration>
A list of valid culture strings can be found in the .NET Framework documentation for the System.Globalization.CultureInfo class.
<httpHandlers> |
<httpHandlers> <add verb=httpVerbs path=pathInfo type=typeInfo validate=boolean /> <remove verb=httpVerbs path=pathInfo /> <clear /> </httpHandlers> |
Adds or removes HttpHandlers, which are used to provide request processing for a specified HTTP verb and/or file type or path. ASP.NET itself is set up as an HttpHandler for .aspx and .asmx files, and HttpHandlers are used to prevent downloading of source code for other ASP.NET file types, such as global.asax.
Any
None
Adds an HttpHandler. The HTTP verbs (GET, POST, etc.) handled by the HttpHandler are specified by the verb attribute; the asterisk (*) wildcard is used to specify all verbs. The path or file extension to be handled by the HttpHandler is specified by the path attribute. The class used to process the request is specified by the type attribute. This class must implement the IHttpHandler interface. Finally, the validate attribute tells ASP.NET whether or not to attempt to load the class specified by the type attribute before a matching request comes in.
Removes a previously configured HttpHandler, based on the specified verb and path attributes. The attributes must match a previously configured <add> element.
Clears all previously configured HttpHandlers.
The example configures a custom HttpHandler for the file extension .aspnetian:
<configuration> <system.web> <httpHandlers> <add verb="*" path="*.aspnetian" type="aspnetian.aspnetianHandler" /> </httpHandlers> </system.web> </configuration>
To make the example work properly, you need to map the file extension .aspnetian to the ASP.NET ISAPI handler, Otherwise, the request would never be handed to the custom HttpHandler. Chapter 9 has a step-by-step walkthrough of the process for mapping additional file types to the ASP.NET ISAPI handler.
<httpModules> |
<httpModules> <add name=moduleName type=typeInfo /> <remove name=moduleName /> <clear /> </httpModules> |
Adds or removes HttpModules. HttpModules are special classes that participate in the processing of all application requests. Both ASP.NET caching and session state are implemented as HttpModules, as are the authentication and authorization features of ASP.NET.
Any
None
Adds an HttpModule. The class that implements the HttpModule is specified by the type attribute. This class must implement the IHttpModule interface. The name attribute provides an alias by which the HttpModule can be referencedfor example, in a later <remove> element.
Removes a previously configured HttpModule, based on the specified name attribute. The attribute must match a previously configured <add> element.
Clears all previously configured HttpModules.
The example removes the HttpModule for the Session state provider, which can be useful if you're not using it:
<configuration> <system.web> <httpModules> <remove name="Session" /> </httpModules> </system.web> </configuration>
If you're not using a particular HttpModule, such as the Session state module or authentication modules, you may be able to save overhead by removing these HttpModules from an application's web.config file by using the <remove> element.