asp.net| schema HttpApplication triggers events to inform your program that something is happening, in order to be responsible for the request flow. This occurs as part of the HttpApplication.Init () function ( Use reflector to view the System.Web.HttpApplication.InitInternal () method and the Httpapplication.resumesteps () method for more details), set up and start a series of events continuously, Includes executing all processors (handler). These event handlers map to which events are automatically generated in Global.asax, and they also map to all attached httpmodule ( They are essentially HttpApplication additional event receivers (sink) that are released externally.
Both HttpModule and HttpHandler are dynamically loaded and attached to the event-handling chain according to the corresponding configuration in Web.config. HttpModule is actually an event handler, attached to a special HttpApplication event, However, HttpHandler is used to process the endpoint of application-level request processing.
Both HttpModule and HttpHandler are loaded in part of the HttpApplication.Init () function call and attached to the call chain. Figure 6 shows the different events, when they occurred, and which part of the pipeline they affect.
Figure 6-The process of the event flowing through the ASP.net HTTP pipeline. Event-driven requests for HttpApplication objects flow through the pipeline. Http module can intercept these events and overwrite or extend existing functionality.
HttpContext, HttpModules and httphandlers.
HttpApplication itself knows nothing about the data sent to the application-it is just a message object that communicates through events. It triggers the event and passes the message to the called function through the HttpContext object. The state data of the actual current request is maintained by the HttpContext object referred to above. It mentions All requests for proprietary data are provided and the request is followed from the start to the end of the pipeline. Figure 7 shows the process in the ASP.net pipeline. Note the context object (that is, the HttpContext), which is always the object of your "friend" from the beginning of the request to the end, You can save information in an event-handling function and take it out in a later event-handler function.
Once the pipe is started, HttpApplication begins to trigger events as shown in Figure six. Each event handler is triggered, and if the event is hooked up, These processors will perform their own tasks. The main task of this process is to ultimately invoke the HttpHandler that is attached to this particular request. Processor (handler) is the core processing mechanism for ASP.NET requests, This is usually where all application-level code is executed. Remember that asp.net pages and Web service frameworks are implemented as HttpHandler, and this is the core of the processing of requests. Modules (module) tend to be passed to the processor (handler) The preprocessing or post processor of the context. Asp. The typical default processors in net include preprocessing authentication, caching, and various coding mechanisms in post processing.
There are a lot of available information about HttpHandler and HttpModule, so in order to keep this article at a reasonable length, I will provide a brief introduction to the processor.
HttpModule
A series of events in the Httpapplicaion object are triggered when the request is passed in the pipeline. We have seen these events published as events in Global.asax. This method is specific to the application, It may not always be what you want. If you want to create a generic HttpApplication event hook that can be plugged into any Web application, you can use HttpModule, which is reusable and does not require specific language application code, Only one entry in the web.config is required.
A module is essentially a filter (Fliter)-functionally similar to an ISAPI filter, but it works at the ASP.net request level. The module allows you to hook up events for each request that passes through the HttpApplication object. These modules are stored as classes in an external assembly. is configured in the Web.config file and is loaded when the application starts. By implementing specific interfaces and methods, the module is hooked up to the HttpApplication event chain. Multiple HttpModule can be hooked up to the same event, The order of event processing depends on the order in which they are declared in Web.config. The following is the processor definition in web.config.
<configuration>
<system.web>
<add name= "Basicauthmodule"
Type= "Httphandlers.basicauth,webstore"/>
</system.web>
</configuration>
Note that you need to specify the full type name and assembly name without the DLL extension.
The module allows you to view each received Web request and perform an action based on the event being triggered. The module does a very good job of modifying requests and response data to provide custom authentication for specific programs or additional preprocessing for each request that occurs in ASP.net/ Post-processing functions. Many asp.net functions, such as the authentication and session (sessions) engine, are implemented as HttpModule.
Although HttpModule looks like an ISAPI filter, they all check for each request that is applied through the asp.net, but they only check for requests that map to a single specific asp.net application or virtual directory. That is, only requests that are mapped to ASP.net are checked. This way you can check all ASPX pages or any other extensions that map to asp.net. You cannot check the standard. htm or picture file unless you explicitly map these extensions to the ASP.net ISAPI dll. As shown in Figure 1. A common such application might be to use modules to filter the content of JPG images in a particular directory and to draw ' samples ' from the top level through GDI +.
Implementing an HTTP module is simple: You must implement a IHttpModule interface that contains two functions (Init () and Dispose ()). The incoming event argument contains a reference to the HttpApplication object. This gives you the ability to access HttpContext objects. In these ways you can hook up to the HttpApplication event. For example, if you want to hook up a AuthenticateRequest event to a module, you just do it as shown in Listing 5
Listing 5: The underlying HTTP module is very easy to implement
public class Basicauthcustommodule:ihttpmodule
{
public void Init (HttpApplication application)
{
Hook up any HttpApplication events
Application. AuthenticateRequest + = new EventHandler (this. OnAuthenticateRequest);
}
public void Dispose () {}
public void OnAuthenticateRequest (object source, EventArgs EventArgs)
{
HttpApplication app = (HttpApplication) source;
HttpContext context = HttpContext.Current;
... do what your have to do ...}
}
Remember that your module accesses the HttpContext object, from which you can access objects that are intrinsic to other asp.net pipelines, such as requests and responses (Response), so that you can also receive information entered by the user, and so on. But remember that some things may not be accessible, They can only be accessed in the backend of the processing chain.
You can hook up multiple events in the init () method, this allows you to implement several different functions in a single module. However, splitting the different logic into separate classes may make the module more clearly modular (the modularity here has nothing to do with the previous modules). In many cases, the functionality you implement may require you to hook up multiple events-for example, a log filter may record the request start time in the BeginRequest event, and then write the request end to the log in the EndRequest event.
Note the focus of a Httomodule and HttpApplication event: Response.End () or httpapplication.completerequest () "Take a shortcut" in the HttpApplication and module event chain. See "Note response.end ()" For more information.
Note Response.End ()
When you create a HttpModule or implement an event hook in Global.asax, when you call Response.End or Pay special attention to appplication.completerequest. Both functions end the current request and stop triggering events that follow in the HTTP pipeline. Then the control is returned to the Web server. When you have a log or an action on the content behind the processing chain, because they are not triggered, you may be fooled. For example, the example of logging in sample will fail because if you call Response.End () , the endrequest event is not triggered.
