老生又长谈：HttpApplication,HttpModule,HttpContext及Asp.Net页生命周期
IIS在接到一个新的http请求后，最终会调用asp.net_isapi.dll的ISAPI扩展(特指IIS6.0环境，iis7.0的应用程序池默认为集成方式，相对有所变化)，然后传递到httpRuntime Pipe(http运行时管道)，Asp.Net这时才开始运行(即HttpRunTime是Asp.Net真正的入口)，HttpRunTime会为每个asp.net应用自动创建一个HttpApplication的实例，而该实例中又包含以下属性:
注1
Application -->相当于传统意义上asp时代的application对象，通常用于定义一个asp.net应用的全局变量
Context -->HttpContext(上下文)类的实例【Asp.Net新增的】
Modules -->影响当前应用程序的HttpModule模块集合
Request -->类似于asp中的Request对象，通常用于接收一些特定的值(比如Request.Form或Request.QueryString)
Response -->类似于asp中的Response对象，通常用于向做页面输出指定内容(比如Resonse.Write)
Server -->类似于asp中的Server对象，通过它能获得一些服务端的信息(比如Server.MapPath)
Session -->类似于asp中的Session对象
User -->用于获取用户认证相关的安全信息
从上面的属性可以发现：很多其实在asp年代已在使用，只有Context,Modules,User这三个是Asp.Net新增的
HttpApplication类除了具备"注1"的几个属性外，还有自己的方法，这里特别提一下Init方法和Dispose方法，这二个方法均可重载.
它们的调用时机为:
Init方法在Application_Start之后调用，而Dispose在Application_End之前调用，另外Application_Start在整个asp.net应用的生命周期内只激发一次(比如IIS启动或网站启动时)，类似的Application_End也只有当asp.net应用程序关闭时被调用(比如IIS停止或网站停止时)
除了Application_Start和Application_End方法，HttpApplication还提供了以下事件:
这些事件包括前面提到的可重载的Init及Dispose方法，再加上Session对应的Session_Start与Session_End方法，均可直接在Global.ascx.cs中以Application_XXX的形式使用(因为Global.ascx.cs中定义的类Global本身就是继承自HttpApplication的)
view source
public class Global : System.Web.HttpApplication
再来看一下相对asp而言，新增的Context,Modules,User这三个属性
Context：
Context即HttpContext类的实例，在几乎整个aspx页面生命周期中，Context上下文一直伴随着各个环节向下传递
所以我们几乎可以在web应用中的任何环节，用HttpContext.Current来引用到当前的上下文实例，从HttpContext的定义上，还可以发现Context本身的属性中，又可以得到Application,ApplicationInstance,Profile,Response.Request...等对象的实例引用
回想一下：
view source
/// <summary>
///Handler1 的摘要说明
/// </summary>
public class Handler1 : IHttpHandler
{public void ProcessRequest(HttpContext context){context.Response.ContentType = "text/plain";context.Response.Write("Hello World");}public bool IsReusable{get{return false;}}
}
我们在使用一个ashx文件时，ProcessRequest方法便是把当前上下文传递进来，进而通过context得到Response对象的引用，最终可以向页面输出任何想要的内容.
Modules:
每一个实现了IHttpModule接口的类，就可以被认为是Http模块组件，可以理解为http请求拦截器，拦截到http请求后，它能修改正在被处理的Context上下文，完事儿之后，再把控制权交还给管道，如果还有其它模块，则依次继续处理，直到所有Modules集合中的HttpModule都“爽”完为止(注：可怜的http请求就这样给各个httpModule轮X了)
asp.net2.0默认内置了很多HttpModule，从Machine.Config文件中可以发现以下默认的内置模块:
注2
AnonymouseIdentification --为匿名用户分配一个临时身份
FileAuthorization --验证用户是否有请求文件的Windows NT许可
FormsAuthentication --窗体身份验证模块(如果没有这个模块,asp.net就无法以用户名/密码[即FOrms]方式验证)
OutputCache --输出缓存模块
PassportAuthentication --PassPort验证模块
Profile --用户配置模块(如果没有它，asp.net中就无法使用Profile)
RoleManager --角色管理
SessionSate --会话状态模块
UrlAuthorization --基于URL的身份验证模块
WindowsAuthentication --Windows和IIS身份验证模块
User：
如果您使用过asp.net2.0内置的Membership/Role机制来进行访问认证，就会对User对象感到很熟悉，比如：
view source
if (HttpContext.Current.User.Identity.IsAuthenticated)
{//用户登录过了...
}
我们常用它来判断当前浏览用户的登录状态，关于User类的更详细定义，可参见MSDN
生命周期：
最后再来回顾一下Asp.Net中Page页的生命周期，Page中定义了几个事件:
总体上讲：一个ASPX页面被请求时，最终的生命周期就是由Page中定义的上述事件(还有一些可重载的回调方法)以及以前提到的HttpApplication类中定义的事件(以相应的回调方法)共同触发或调用，最终叠加形成的一连串处理过程。
如果先不考虑HttpApplication中的事件处理方法(即不考虑我们在Global.ascx.cs中定义的Application_XXX处理方法)，Page中的事件(方法)常规触发(调用)顺序为：
01.Page_PreInit
02.Page_Init
03.Page_InitComplete
04.Page_PreLoad
05.Page_Load
06.Page_LoadComplete
07.Page_PreRender
08.Page_SaveStateComplete
09.Page_Unload
这是在Page页面未回发，且不考虑页面子控件的前提下正常的顺序，如果加入页面回发(比如在页面中放一个asp:Button，然后在Button的Click回发事件中加入处理函数)后，顺序稍微有些变化：
01.Page_PreInit
02.Page_Init
03.Page_InitComplete
04.Page_PreLoad
05.Page_Load
06.Button1_Click
07.Page_LoadComplete
08.Page_PreRender
09.Page_SaveStateComplete
10.Page_Unload
不同的地方在于：回发事件Button1_Click在Page_Load后被触发.
最后再把HttpApplication的事件考虑进来，看下叠加后的顺序，不过先别着急，我们先来看一种特殊情况，如果一个asp.net应用根目录下未设置默认页，这时直接浏览根目录，比如http://localhost:2345/ 时，Globl.ascx.cs中定义的Application_XXX方法的调用顺序如下：
2011-05-03 15:01:39 413 Application_Start
2011-05-03 15:01:39 491 Init
2011-05-03 15:01:39 491 Application_BeginRequest
2011-05-03 15:01:39 506 Application_AuthenticateRequest
2011-05-03 15:01:39 506 Application_PostAuthenticateRequest
2011-05-03 15:01:39 506 Application_AuthorizeRequest
2011-05-03 15:01:39 522 Application_PostAuthorizeRequest
2011-05-03 15:01:39 522 Application_ResolveRequestCache
2011-05-03 15:01:39 522 Application_PostResolveRequestCache
2011-05-03 15:01:39 522 Application_PostMapRequestHandler
2011-05-03 15:01:39 522 Application_AcquireRequestState
2011-05-03 15:01:39 537 Application_PostAcquireRequestState
2011-05-03 15:01:39 537 Application_PreRequestHandlerExecute
2011-05-03 15:01:39 553 Application_Error
2011-05-03 15:01:39 553 Application_EndRequest
2011-05-03 15:01:39 569 Application_PreSendRequestHeaders
2011-05-03 15:01:39 569 Application_PreSendRequestContent
可以看到会触发Application_Error事件，即HttpRuntime认为这是一个错误.
紧接着再浏览一个实际存在的页面，如果这时应用程序有严重错误，导致Application关闭(比如web.config配置错误)，调用的顺序如下:
2011-05-03 15:03:47 704 Application_BeginRequest
2011-05-03 15:03:47 704 Application_AuthenticateRequest
2011-05-03 15:03:47 766 Application_PostAuthenticateRequest
2011-05-03 15:03:47 766 Application_AuthorizeRequest
2011-05-03 15:03:47 766 Application_PostAuthorizeRequest
2011-05-03 15:03:47 766 Application_ResolveRequestCache
2011-05-03 15:03:47 783 Application_PostResolveRequestCache
2011-05-03 15:03:48 667 Application_PostMapRequestHandler
2011-05-03 15:03:48 667 Application_AcquireRequestState
2011-05-03 15:03:48 683 Application_PostAcquireRequestState
2011-05-03 15:03:48 698 Application_PreRequestHandlerExecute
2011-05-03 15:03:48 745 Page_PreInit
2011-05-03 15:04:02 903 Page_Unload
2011-05-03 15:04:02 903 Application_Error
2011-05-03 15:04:02 918 Application_EndRequest
2011-05-03 15:04:02 996 Application_PreSendRequestHeaders
2011-05-03 15:04:02 996 Application_PreSendRequestContent
2011-05-03 15:04:03 371 Application_Disposed
2011-05-03 15:04:03 371 Dispose
2011-05-03 15:04:03 386 Application_End
对比刚才的顺序，会发现Application_Start及Init没有再次被调用，也印证了文章前面提到的一些结论(Application_Start在整个asp.net应用生命周期内只触发一次)，而且从最后的三个输出能知道：应用程序关闭时Application_Disposed,Dispose,Application_End按顺序调用.
再"重新"浏览(指web Server重启)一下正常访问的页面，在不出错也不回发的情况下，顺序如下:
2011-05-03 15:08:11 513 Application_Start
2011-05-03 15:08:11 591 Init
2011-05-03 15:08:11 591 Application_BeginRequest
2011-05-03 15:08:11 591 Application_AuthenticateRequest
2011-05-03 15:08:11 591 Application_PostAuthenticateRequest
2011-05-03 15:08:11 606 Application_AuthorizeRequest
2011-05-03 15:08:11 606 Application_PostAuthorizeRequest
2011-05-03 15:08:11 606 Application_ResolveRequestCache
2011-05-03 15:08:11 606 Application_PostResolveRequestCache
2011-05-03 15:08:11 622 Application_PostMapRequestHandler
2011-05-03 15:08:11 637 Application_EndRequest
2011-05-03 15:08:11 637 Application_PreSendRequestHeaders
2011-05-03 15:08:11 637 Application_PreSendRequestContent
2011-05-03 15:08:11 637 Application_BeginRequest
2011-05-03 15:08:11 637 Application_AuthenticateRequest
2011-05-03 15:08:11 653 Application_PostAuthenticateRequest
2011-05-03 15:08:11 653 Application_AuthorizeRequest
2011-05-03 15:08:11 653 Application_PostAuthorizeRequest
2011-05-03 15:08:11 653 Application_ResolveRequestCache
2011-05-03 15:08:11 653 Application_PostResolveRequestCache
2011-05-03 15:08:11 653 Application_PostMapRequestHandler
2011-05-03 15:08:11 653 Session_Start
2011-05-03 15:08:11 653 Application_AcquireRequestState
2011-05-03 15:08:11 653 Application_PostAcquireRequestState
2011-05-03 15:08:11 653 Application_PreRequestHandlerExecute
2011-05-03 15:08:11 669 Page_PreInit
2011-05-03 15:08:11 684 Page_Init
2011-05-03 15:08:11 684 Page_InitComplete
2011-05-03 15:08:11 684 Page_PreLoad
2011-05-03 15:08:11 684 Page_Load
2011-05-03 15:08:11 684 Page_LoadComplete
2011-05-03 15:08:11 684 Page_PreRender
2011-05-03 15:08:11 684 Page_SaveStateComplete
2011-05-03 15:08:11 700 Page_Unload
2011-05-03 15:08:11 700 Application_PostRequestHandlerExecute
2011-05-03 15:08:11 700 Application_ReleaseRequestState
2011-05-03 15:08:11 700 Application_PostReleaseRequestState
2011-05-03 15:08:11 700 Application_UpdateRequestCache
2011-05-03 15:08:11 700 Application_PostUpdateRequestCache
2011-05-03 15:08:11 700 Application_EndRequest
2011-05-03 15:08:11 700 Application_PreSendRequestHeaders
2011-05-03 15:08:11 700 Application_PreSendRequestContent
2011-05-03 15:08:11 793 Application_BeginRequest
2011-05-03 15:08:11 793 Application_AuthenticateRequest
2011-05-03 15:08:11 793 Application_PostAuthenticateRequest
2011-05-03 15:08:11 793 Application_AuthorizeRequest
2011-05-03 15:08:11 793 Application_PostAuthorizeRequest
2011-05-03 15:08:11 793 Application_ResolveRequestCache
2011-05-03 15:08:11 793 Application_PostResolveRequestCache
2011-05-03 15:08:11 809 Application_PostMapRequestHandler
2011-05-03 15:08:11 809 Application_AcquireRequestState
2011-05-03 15:08:11 809 Application_PostAcquireRequestState
2011-05-03 15:08:11 809 Application_PreRequestHandlerExecute
2011-05-03 15:08:11 825 Application_PostRequestHandlerExecute
2011-05-03 15:08:11 825 Application_ReleaseRequestState
2011-05-03 15:08:11 840 Application_PostReleaseRequestState
2011-05-03 15:08:11 949 Application_UpdateRequestCache
2011-05-03 15:08:11 949 Application_PostUpdateRequestCache
2011-05-03 15:08:11 965 Application_EndRequest
2011-05-03 15:08:11 981 Application_PreSendRequestHeaders
2011-05-03 15:08:11 981 Application_PreSendRequestContent
哇！原来一个页面访问下来，会调用到这么多的方法，怪不得很多高并发的大型网站，通常都要自己写一个精减的HttpHandler用来取代Page做为基类，以期望获得更好的性能
更准确的页面生命周期解释，请查阅下面的文档，这是msdn官方网站对于Asp.Net页面生命周期的权威解释
文中源码 留下QQ号码，或加QQ:691647004 一起讨论
转载于:https://www.cnblogs.com/boyjsj/archive/2011/05/05/abouthttp.html
老生又长谈：HttpApplication,HttpModule,HttpContext及Asp.Net页生命周期相关推荐
- 温故而知新：HttpApplication,HttpModule,HttpContext及Asp.Net页生命周期
IIS在接到一个新的http请求后,最终会调用asp.net_isapi.dll的ISAPI扩展(特指IIS6.0环境,iis7.0的应用程序池默认为集成方式,相对有所变化),然后传递到httpRun ...
- ASP.NET页生命周期概述
ASP.NET页生命周期的定义,有以下8个方面:页请求,开始,页初始化,页加载,验证,回发事件,呈现,卸载. ASP.NET 页运行时,此页将经历一个生命周期,在生命周期中将执行一系列处理步骤.这些步 ...
- .NET与java的MVC模式(3):ASP.NET 页生命周期概述
ASP.NET 页生命周期概述 来源:MSDN ASP.NET 页运行时,此页将经历一个生命周期,在生命周期中将执行一系列处理步骤.这些步骤包括初始化.实例化控件.还原和维护状态.运行事件处理程序代码 ...
- 学习笔记--asp.net页生命周期（转自msdn，仅为自己学习存储和有意读者使用）
ASP.NET 页生命周期概述 .NET Framework 4 其他版本 28(共 30)对本文的评价是有帮助 - 评价此主题 更新:2011 年 5 月 ASP.NET 页运行时,此页将经历一个生 ...
- ASP.NET页生命周期介绍：阶段，事件及其他
ASP.NET页生命周期介绍:阶段,事件及其他 本文概述了asp.net的页生命周期.在页生命周期的每个阶段中,页将引发可运行您自己的代码进行处理的事件. asp.net 页运行时,此页将经历一个生命 ...
- .NET ASP.NET 页生命周期概述
ASP.NET 页生命周期概述 ASP.NET 页运行时,此页将经历一个生命周期,在生命周期中将执行一系列处理步骤. 这些步骤包括初始化.实例化控件.还原和维护状态.运行事件处理程序代码以及进行呈现. ...
- ASP.NET 页生命周期概述
ASP.NET 页运行时,此页将经历一个生命周期,在生命周期中将执行一系列处理步骤.这些步骤包括初始化.实例化控件.还原和维护状态.运行事件处理程序代码以及进行呈现.了解页生命周期非常重要,因为这样做 ...
- asp.net页生命周期
asp.net页运行时,此页将经历一个生命周期,在生命周期中将执行一系列处理步骤.这些步骤包括初始化,实例化控件,还原和维护状态,运行事件处理程序代码以及进行呈现. 除了页生命周期阶段以外, ...
- ASP.NET 页生命周期
参考:http://msdn.microsoft.com/zh-cn/library/ms178472(v=vs.100).aspx 转载于:https://www.cnblogs.com/pengp ...
最新文章
- GitHub标星2.6万！Python算法新手入门大全
- winfrom 点击按钮button弹框显示颜色集
- 如何设置电脑开机自动提示(防止忘打卡等)
- python四大器_Python编程四大神兽：迭代器、生成器、闭包和装饰器
- Linux挂载iso文件步骤
- android markdown 框架,Android Studio MarkDown风格README的正确打开姿势
- MYSQL 用户的操作
- 奇怪的315：大家都知道，为什么要等晚会曝光，管理部门呢
- 一步到位：手把手教你R语言竞争风险模型建模-列线图-校准曲线-K折验证-外部验证- 决策曲线
- NPOI实现Word表格删除一行
- UE5 Oculus Quest 2 VR中设置手柄摇杆移动蓝图
- 【c++】保留两位小数
- TeamTalk源码分析（二） —— 服务器端的程序的编译与部署
- 聚星完整源码 UI超级好看+对接NG接口+双玩系统
- ava web开发 高并发处理
- TypeScript 研发规约落地实践
- 寒假2018培训：DAY1
- 关于面粉品质快速检测的方法
- [论文阅读笔记58]Learning from Noisy Labels with Deep Neural Networks：A Survey
- 如何将程序下载到芯昇科技MCU芯片中
热门文章
- linux php运行用户名和密码,Linux实例（一）使用用户名密码验证连接Linux
- centeros6.8 mysql_centeros7安装mysql8，以及设置root密码
- python 动态规划_DP动态规划（Python实现）
- python和office_Python在office开发中的应用
- c++ map 析构函数_C++｜类继承关系中的虚函数、虚析构函数、虚基类
- fedora java 开发环境_在Linux(Fedora)下搭建JAVA开发环境
- pyautogui 打包 运行 窗口_试试动态窗口管理器 dwm 吧
- Python打卡第四周
- Dockerfile构建容器镜像 - 运维笔记
- 第十九章 我国农村资金筹集