ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

时间:2022-10-31 21:28:01

开篇:上一篇我们了解了一个请求从客户端发出到服务端接收并转到ASP.Net处理入口的过程,这篇我们开始探索ASP.Net的核心处理部分,借助强大的反编译工具,我们会看到几个熟悉又陌生的名词(类):HttpRuntime、HttpWorkerRequest、HttpContext、HttpApplication等。

(1)Part 1:前奏

(2)Part 2:核心

(3)Part 3:管道

(4)Part 4:WebForm页面生命周期

(5)Part 5:MVC页面声命周期

一、第一个入口:ISAPIRuntme.ProcessRequest()

  ISAPIRuntime是进入NET托管环境的入口,它在方法中通过一个ecb句柄指向了当前请求报文体的内存地址,将HTTP请求报文简单封装为一个HttpWorkerRequest对象,然后就是各种我们经常听到的PR(ProcessRequest)方法了。

①调用ISAPIRuntime对象的ProcessRequest方法进入ASP.NET处理流程

  通过Reflector,我们可以看到在ISAPIRuntime中的这个入口方法:ProcessRequest

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

②首先根据ecb句柄创建HttpWorkerRequest对象封装原始请求报文

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

关于HttpWorkerRequest:

在Asp.Net中准备用于处理的请求,都必须封装为HttpWorkerRequest类型的对象,HttpWorkerRequest是一个抽象类型。这里创建的是一个ISAPIWorkerRequest类型,它继承于HttpWorkerRequest类。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
[ComVisible(false)]
public abstract class HttpWorkerRequest
{
// Fields
private DateTime _startTime;
private Guid _traceId;
......
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  转到ISAPIWorkerRequest类的CreateWorkerRequest方法中,看到首先判断当前IIS服务器的版本(IIS6 or IIS7?),然后创建适合不同IIS的具体WorkerRequest对象,默认都是InProc进程内的,当然,也有OutOfProc进程外的。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
internal static ISAPIWorkerRequest CreateWorkerRequest(IntPtr ecb, bool useOOP)
{
if (useOOP)
{
EtwTrace.TraceEnableCheck(EtwTraceConfigType.DOWNLEVEL, IntPtr.Zero);
if (EtwTrace.IsTraceEnabled(5, 1))
{
EtwTrace.Trace(EtwTraceType.ETW_TYPE_APPDOMAIN_ENTER, ecb, Thread.GetDomain().FriendlyName, null, false);
}
return new ISAPIWorkerRequestOutOfProc(ecb);
}
int num = UnsafeNativeMethods.EcbGetVersion(ecb) >> 0x10;
if (num >= 7)
{
EtwTrace.TraceEnableCheck(EtwTraceConfigType.IIS7_ISAPI, ecb);
}
else
{
EtwTrace.TraceEnableCheck(EtwTraceConfigType.DOWNLEVEL, IntPtr.Zero);
}
if (EtwTrace.IsTraceEnabled(5, 1))
{
EtwTrace.Trace(EtwTraceType.ETW_TYPE_APPDOMAIN_ENTER, ecb, Thread.GetDomain().FriendlyName, null, true);
}
if (num >= 7)
{
return new ISAPIWorkerRequestInProcForIIS7(ecb);
}
if (num == 6)
{
return new ISAPIWorkerRequestInProcForIIS6(ecb);
}
return new ISAPIWorkerRequestInProc(ecb);
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  由于HttpWorkerRequest类封装的请求报文很原始,很复杂,所以微软没有将其公开出来。

二、第二个入口:HttpRuntime.ProcessRequest()

  HttpRuntime是ASP.NET请求处理的第二个入口。当请求进来,首先进入HttpRuntime,由HttpRuntime来决定如何处理请求。默认情况下,在machine.config和Web.config中并没有显式定义httpRuntime节点,但该节点是有默认值的,如下:

  通常情况下,我们可以在Web.config中更改httpRuntime节点的默认值,如下:

①其次执行HttpRuntime的ProcessRequestNoDemand方法封装HttpContext对象

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  在HttpRuntime类中,有一个称为ProcessRequestNoDemand的静态方法。这里创建并初始化HttpWorkerRequest对象后,调用了HttpRuntime的这个ProcessRequestNoDemand方法。于是,我们转到ProcessRequestNoDemand方法,可以看到如下代码:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
internal static void ProcessRequestNoDemand(HttpWorkerRequest wr)
{
RequestQueue queue = _theRuntime._requestQueue;
wr.UpdateInitialCounters();
if (queue != null)
{
wr = queue.GetRequestToExecute(wr);
}
if (wr != null)
{
CalculateWaitTimeAndUpdatePerfCounter(wr);
wr.ResetStartTime();
ProcessRequestNow(wr);
}
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  该方法先从请求队列中取出一个请求,然后更新请求的引用计数器的信息,然后再将HttpWorkerRequest对象传入ProcessRequestNow方法来处理请求。

  这里我们还可以看到_theRuntime这个字段,它是HttpRuntime类的一个静态字段,在HttpRuntime的静态构造函数中进行初始化。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
public sealed class HttpRuntime
{
// Fields
......
private static HttpRuntime _theRuntime;
......
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  再回到ProcessRequestNoDemand方法中,我们看到最后是由ProcessRequestNow方法来接棒。于是,我们转到ProcessRequestNow方法再来看看:

internal static void ProcessRequestNow(HttpWorkerRequest wr)
{
_theRuntime.ProcessRequestInternal(wr);
}

  我们看到在这个方法中又调用了_theRuntime的实例方法:ProcessRequestInternal,还是把HttpWorkerRequest对象作为参数传递了过去。于是,我们再转到ProcessRequestInternal这个方法中,发现了一个重要的对象:HttpContext对象。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private void ProcessRequestInternal(HttpWorkerRequest wr)
{
Interlocked.Increment(ref this._activeRequestCount);
if (this._disposingHttpRuntime)
{
......
}
else
{
HttpContext context;
try
{
context = new HttpContext(wr, false);
}
catch
{
try
{
wr.SendStatus(400, "Bad Request");
wr.SendKnownResponseHeader(12, "text/html; charset=utf-8");
byte[] data = Encoding.ASCII.GetBytes("<html><body>Bad Request</body></html>");
wr.SendResponseFromMemory(data, data.Length);
wr.FlushResponse(true);
wr.EndOfRequest();
return;
}
finally
{
Interlocked.Decrement(ref this._activeRequestCount);
}
}
......
}
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  在HttpContext的构造函数中,根据HttpWorkerRequest对象创建了HttpContext对象,这是一个重要的Http上下文对象,两个重要类型的字段也随之被初始化:HttpRequest对象和HttpResponse对象。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  相信大家在进行ASP.NET开发时,经常使用这两个类型的实例。例如,我们可以通过HttpContext.Current获取到这个实例,且该实例会在整个生命周期中存活,我们通过它可以获取到一些常用对象,如Request,Response,Session 等。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

②通过HttpApplicationFactory得到一个具体的HttpApplication实例

  让我们再次回到HttpRuntimeProcessRequestInternal这个方法中,刚刚HttpContext对象被创建后,紧接着又干了什么事?让我们看看源码:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private void ProcessRequestInternal(HttpWorkerRequest wr)
{
Interlocked.Increment(ref this._activeRequestCount);
if (this._disposingHttpRuntime)
{
......
}
else
{
HttpContext context;
......
IHttpHandler applicationInstance = HttpApplicationFactory.GetApplicationInstance(context);
......
if (applicationInstance is IHttpAsyncHandler)
{
IHttpAsyncHandler handler2 = (IHttpAsyncHandler) applicationInstance;
context.AsyncAppHandler = handler2;
handler2.BeginProcessRequest(context, this._handlerCompletionCallback, context);
}
else
{
applicationInstance.ProcessRequest(context);
this.FinishRequest(context.WorkerRequest, context, null);
}
......
}
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  首先,我们看到了一个非常熟悉的字眼:IHttpHandler,我们的ashx、aspx不都是实现了这个IHttpHandler接口的吗?于是,我们来看看这句:IHttpHandler applicationInstance = HttpApplicationFactory.GetApplicationInstance(context); 它是通过一个叫做HttpApplicationFactory的工厂类来获取了一个HttpApplication的实例,并将HttpContext上下文对象作为参数传递了进去。于是,怀着好奇心,我们转到这个方法内部去看看:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
internal static IHttpHandler GetApplicationInstance(HttpContext context)
{
......
    _theApplicationFactory.EnsureInited();
_theApplicationFactory.EnsureAppStartCalled(context);
    return _theApplicationFactory.GetNormalApplicationInstance(context); 
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  原来,它是调用了一个实例方法:GetNormalApplicationInstance来获取HttpApplication。于是,我们再转到这个方法的内部去看看:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private HttpApplication GetNormalApplicationInstance(HttpContext context)
{
HttpApplication state = null;
lock (this._freeList)
{
if (this._numFreeAppInstances > 0)
{
state = (HttpApplication) this._freeList.Pop();
this._numFreeAppInstances--;
if (this._numFreeAppInstances < this._minFreeAppInstances)
{
this._minFreeAppInstances = this._numFreeAppInstances;
}
}
}
if (state == null)
{
state = (HttpApplication) HttpRuntime.CreateNonPublicInstance(this._theApplicationType);
using (new ApplicationImpersonationContext())
{
state.InitInternal(context, this._state, this._eventHandlerMethods);
}
}
......
return state;
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  通过查看这段代码,它首先维护着一个HttpApplication池(_freeList,本质上就是一个Stack栈),然后判断可用的HttpApplication实例的数量(_numFreeAppInstances)是否大于0?如果存在可用的,则从池中出栈,然后将可用数量减1。最后,再判断可用的数量是否小于最低限制的数量,如果小于那么则将最低限制的数量设置为目前可用的数量。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  那么,如果目前HttpApplication池暂时没有可用的实例呢?我们看到了这一句:state = (HttpApplication) HttpRuntime.CreateNonPublicInstance(this._theApplicationType); 通过此段代码,新建了一个新的HttpApplication实例,通过继续深入查看,原来是通过反射的方式将Global文件所编译后的类封装出来一个HttpApplication实例。

补充之一:_theApplicationType是_theApplicationFactory.EnsureInited();中被赋值的

private void CompileApplication()
{
this._theApplicationType = BuildManager.GetGlobalAsaxType();
......
}

补充之二:全局事件中例如Application_Start方法如何保证只执行一次?在_theApplicationFactory.EnsureAppStartCalled(context);方法中,判断_appOnStartCalled标志,如果是false则调用FireApplicationOnStart方法触发Application_Start方法,然后更改_appOnStartCalled标志。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private void EnsureAppStartCalled(HttpContext context)
{
if (!this._appOnStartCalled)
{
lock (this)
{
if (!this._appOnStartCalled)
{
using (new DisposableHttpContextWrapper(context))
{
......
this.FireApplicationOnStart(context);
}
this._appOnStartCalled = true;
}
}
}
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

三、第三个入口:HttpApplication.Init()

  在前两个入口中,HttpApplication实例被创建,现在HttpApplication需要进行初始化请求处理管道,来分别处理ASP.Net WebForm或ASP.Net MVC等类型的页面的响应操作。

①初始化HttpModules

  让我们再次回到HttpRuntime的ProcessRequestInternal这个方法中,刚刚HttpApplication实例被创建后,开始了一系列的初始化操作,如下图所示,调用了其InitInternal方法进行了初始化。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  转到InitInternal方法内部,发现调用了一个非常重要的方法:InitModules()。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
internal void InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers)
{
this._state = state;
PerfCounters.IncrementCounter(AppPerfCounter.PIPELINES);
try
{
......
this.InitModules();
......
if (HttpRuntime.UseIntegratedPipeline)
{
this._stepManager = new PipelineStepManager(this);
}
     else
     {
        this._stepManager = new ApplicationStepManager(this);
      }
      this._stepManager.BuildSteps(this._resumeStepsWaitCallback);
   }
catch
{
......
   }
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  在InitModules这个方法中,首先通过读取Web.config配置文件中关于HttpModule的信息,然后将其传递给HttpModule的集合,如下代码所示:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private void InitModules()
{
HttpModuleCollection modules = RuntimeConfig.GetAppConfig().HttpModules.CreateModules();
HttpModuleCollection other = this.CreateDynamicModules();
modules.AppendCollection(other);
this._moduleCollection = modules;
this.InitModulesCommon();
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  然后,调用InitModulesCommon方法,遍历上面这个_moduleCollection集合,分别对其每一个HttpModule执行其对应的Init方法。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private void InitModulesCommon()
{
int count = this._moduleCollection.Count;
for (int i = 0; i < count; i++)
{
this._currentModuleCollectionKey = this._moduleCollection.GetKey(i);
this._moduleCollection[i].Init(this);
}
this._currentModuleCollectionKey = null;
this.InitAppLevelCulture();
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

注册19个请求处理管道事件

  接上述操作之后,InitInternal方法内部还执行了这样一句:this._stepManager.BuildSteps(this._resumeStepsWaitCallback); 它完成了19个请求处理管道事件的注册工作。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
internal override void BuildSteps(WaitCallback stepCallback)
{
ArrayList steps = new ArrayList();
HttpApplication app = base._application;
bool flag = false;
UrlMappingsSection urlMappings = RuntimeConfig.GetConfig().UrlMappings;
flag = urlMappings.IsEnabled && (urlMappings.UrlMappings.Count > 0);
steps.Add(new HttpApplication.ValidateRequestExecutionStep(app));
steps.Add(new HttpApplication.ValidatePathExecutionStep(app));
if (flag)
{
steps.Add(new HttpApplication.UrlMappingsExecutionStep(app));
} /* 以下代码完成19个事件的注册 */
app.CreateEventExecutionSteps(HttpApplication.EventBeginRequest, steps);
app.CreateEventExecutionSteps(HttpApplication.EventAuthenticateRequest, steps);
app.CreateEventExecutionSteps(HttpApplication.EventDefaultAuthentication, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPostAuthenticateRequest, steps);
app.CreateEventExecutionSteps(HttpApplication.EventAuthorizeRequest, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPostAuthorizeRequest, steps);
app.CreateEventExecutionSteps(HttpApplication.EventResolveRequestCache, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPostResolveRequestCache, steps);
steps.Add(new HttpApplication.MapHandlerExecutionStep(app));
app.CreateEventExecutionSteps(HttpApplication.EventPostMapRequestHandler, steps);
app.CreateEventExecutionSteps(HttpApplication.EventAcquireRequestState, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPostAcquireRequestState, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPreRequestHandlerExecute, steps);
steps.Add(app.CreateImplicitAsyncPreloadExecutionStep());
steps.Add(new HttpApplication.CallHandlerExecutionStep(app));
app.CreateEventExecutionSteps(HttpApplication.EventPostRequestHandlerExecute, steps);
app.CreateEventExecutionSteps(HttpApplication.EventReleaseRequestState, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPostReleaseRequestState, steps);
steps.Add(new HttpApplication.CallFilterExecutionStep(app));
app.CreateEventExecutionSteps(HttpApplication.EventUpdateRequestCache, steps);
app.CreateEventExecutionSteps(HttpApplication.EventPostUpdateRequestCache, steps);
this._endRequestStepIndex = steps.Count;
app.CreateEventExecutionSteps(HttpApplication.EventEndRequest, steps);
steps.Add(new HttpApplication.NoopExecutionStep());
this._execSteps = new HttpApplication.IExecutionStep[steps.Count];
steps.CopyTo(this._execSteps);
this._resumeStepsWaitCallback = stepCallback;
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  从上面的代码可知,ApplicationStepManager对象的BuildSteps方法被调用,完成HttpApplication 19个管道事件的注册。这个方法很重要,它将创建各种HttpApplication.IExecutionStep保存到一个数组列表 _execSteps 中:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
internal override void BuildSteps(WaitCallback stepCallback)
{
.....
this._execSteps = new HttpApplication.IExecutionStep[steps.Count];
steps.CopyTo(this._execSteps);
.....
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  这样做的目的在于:便于在后面的BeginProcessRequest方法内部调用ResumeSteps方法依次执行这些对象的Execute()方法,完成各个事件的执行。

③开始依次处理请求处理管道中的各个事件

  让我们再返回到HttpRuntime中的ProcessRequestInternal方法中,HttpApplication实例已创建好,HttpModules已初始化,请求处理管道中的19个事件也已经注册好,现在需要的只是一一调用HttpModule中各个事件对应的执行方法即可。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
private void ProcessRequestInternal(HttpWorkerRequest wr)
{
......
if (applicationInstance is IHttpAsyncHandler)
{
IHttpAsyncHandler handler2 = (IHttpAsyncHandler) applicationInstance;
context.AsyncAppHandler = handler2;
handler2.BeginProcessRequest(context, this._handlerCompletionCallback, context);
}
......
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  在上述代码中,通过执行BeginProcessRequest方法,触发了ResumeSteps方法依次执行每个请求处理管道事件,也就进入了我们所说的“请求处理管道”中。

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)
IAsyncResult IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, object extraData)
{
this._context = context;
this._context.ApplicationInstance = this;
this._stepManager.InitRequest();
this._context.Root();
HttpAsyncResult result = new HttpAsyncResult(cb, extraData);
this.AsyncResult = result;
if (this._context.TraceIsEnabled)
{
HttpRuntime.Profile.StartRequest(this._context);
}
// 依次执行各个请求处理管道事件
this.ResumeSteps(null);
return result;
}
ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

关于请求处理管道:

HttpApplication 采用处理管道的方法进行处理,将处理的过程分成多个步骤,每个步骤通过事件的形式暴露给程序员,这些事件按照固定的处理顺序依次触发,程序员通过编写事件处理方法就可以自定义每一个请求的扩展处理过程。

对于 HttpApplication 来说,到 ASP.NET 4.0 版本,提供了19 个标准事件,如下图所示:

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  至于在请求处理管道中的细节,我们在Part 3中再看,今天就到此为止,谢谢!

四、核心过程总览

①ISAPIRuntime->HttpWorkerRequest->HttpRuntime

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

②HttpRuntime->HttpContext->HttpApplication

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

③到目前为止的总体流程概览

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)

  • 首先,我们从自己的浏览器通过网络访问Web服务器
  • 当ASP.NET接收到第一个请求时,将会创建一个应用程序域,然后会创建一个宿主环境
  • 然后ASP.NET创建并初始化核心对象HttpContext、HttpRequest和HttpResponse
  • 然后创建HttpApplication对象的实例来启动应用程序
  • 通过进入请求处理管道来处理具体的请求

参考资料

(1)Darren Ji,《ASP.NET MVC请求处理管道声明周期的19个关键环节》:http://www.cnblogs.com/darrenji/p/3795661.html

(2)木宛城主,《ASP.NET那点不为人知的事儿》:http://www.cnblogs.com/OceanEyes/archive/2012/08/13/aspnetEssential-1.html

(3)Tony He,《ASP.NET请求处理机制》:http://www.cnblogs.com/cilence/archive/2012/05/28/2520712.html

(4)两会的博客,《IIS是怎样处理ASP.NET请求的》:http://www.cnblogs.com/hkncd/archive/2012/03/23/2413917.html

(5)wjn2000,《ASP.NET请求处理过程(IIS6)》:http://www.cnblogs.com/wjn2010/archive/2011/04/21/2024341.html

(6)农村出来的大学生,《ASP.NET网页请求处理全过程(反编译)》:http://www.cnblogs.com/poorpan/archive/2011/09/25/2190308.html

ASP.Net请求处理机制初步探索之旅 - Part 2 核心(转)的更多相关文章

  1. ASP&period;Net请求处理机制初步探索之旅 - Part 2 核心

    开篇:上一篇我们了解了一个请求从客户端发出到服务端接收并转到ASP.Net处理入口的过程,这篇我们开始探索ASP.Net的核心处理部分,借助强大的反编译工具,我们会看到几个熟悉又陌生的名词(类):Ht ...

  2. ASP&period;Net请求处理机制初步探索之旅 - Part 1 前奏

    开篇:ASP.Net是一项动态网页开发技术,在历史发展的长河中WebForm曾一时成为了ASP.Net的代名词,而ASP.Net MVC的出现让这项技术更加唤发朝气.但是,不管是ASP.Net Web ...

  3. ASP&period;Net请求处理机制初步探索之旅 - Part 3 管道

    开篇:上一篇我们了解了一个ASP.Net页面请求的核心处理入口,它经历了三个重要的入口,分别是:ISAPIRuntime.ProcessRequest().HttpRuntime.ProcessReq ...

  4. ASP&period;Net请求处理机制初步探索之旅 - Part 3 管道&lpar;转&rpar;

    开篇:上一篇我们了解了一个ASP.Net页面请求的核心处理入口,它经历了三个重要的入口,分别是:ISAPIRuntime.ProcessRequest().HttpRuntime.ProcessReq ...

  5. 【转载】ASP&period;Net请求处理机制初步探索之旅 - Part 3 管道

    开篇:上一篇我们了解了一个ASP.Net页面请求的核心处理入口,它经历了三个重要的入口,分别是:ISAPIRuntime.ProcessRequest().HttpRuntime.ProcessReq ...

  6. ASP&period;Net请求处理机制初步探索之旅 - Part 1 前奏&lpar;转&rpar;

        在读本文之前建议先阅读IIS架构:http://www.cnblogs.com/tiantianle/p/5079932.html     不管是ASP.Net WebForm还是ASP.Ne ...

  7. ASP&period;Net请求处理机制初步探索之旅 - Part 5 ASP&period;Net MVC请求处理流程

    好听的歌 我一直觉得看一篇文章再听一首好听的歌,真是种享受.于是,我在这里嵌入一首好听的歌,当然你觉得不想听的话可以点击停止,歌曲 from 王菲 <梦中人>: --> 开篇:上一篇 ...

  8. ASP&period;Net请求处理机制初步探索之旅 - Part 4 WebForm页面生命周期

    开篇:上一篇我们了解了所谓的请求处理管道,在众多的事件中微软开放了19个重要的事件给我们,我们可以注入一些自定义的业务逻辑实现应用的个性化设计.本篇,我们来看看WebForm模式下的页面生命周期. ( ...

  9. &lpar;转&rpar;Asp&period;Net 请求处理机制

    原文:http://www.cnblogs.com/cilence/archive/2012/05/28/2520712.html Asp.Net 请求处理机制   前言 我们都知道Web请求响应是基 ...

随机推荐

  1. 1002 Phone Numbers 解题报告

    1002. Phone Numbers Time limit: 2.0 secondMemory limit: 64 MB In the present world you frequently me ...

  2. spring MVC原理

    spring MVC原理   Spring MVC工作流程图   图一   图二    Spring工作流程描述       1. 用户向服务器发送请求,请求被Spring 前端控制Servelt D ...

  3. &lbrack;CMD&rsqb;oracle数据库的导出导入

    除了推荐使用PL/SQL Developer 工具对oracle进行导出导入(http://www.cnblogs.com/whylaughing/p/5983490.html )之外,比较常用的还有 ...

  4. Win7 &plus; ubuntu14&period;04 双系统安装教程

    安装主要分为以下几步: 一. 下载Ubuntu 14.04镜像软件: 二. 制作U盘启动盘: 三. 安装Ubuntu系统: 四. 用EasyBCD 创建启动系统. 1. 下载 Ubuntu 14.04 ...

  5. API23时权限不被许可

    In Android 6.0 Marshmallow, application will not be granted any permission at installation time. Ins ...

  6. iOS中僵尸对象的实现方法

    什么是僵尸对象?所谓僵尸,就是过度释放的对象.在ios开发中,僵尸对象对于开发人员调试程序来说很有用.我们通常将NSZombieEnabled环境变量设置为YES来打开僵尸对象,但这会导致所有的对象都 ...

  7. 编程算法 - 有序双循环链表的插入 代码&lpar;C&rpar;

    有序双循环链表的插入 代码(C) 本文地址: http://blog.csdn.net/caroline_wendy 有序双循环链表的插入, 须要找到插入位置, 能够採用, 两个指针, 一个在前, 一 ...

  8. Extjs grid column里添加button等html标签,并增加点击事件

    Extjs里有个actioncolumn,但actioncolumn只能添加一系列button,不能既有字又有button 如何能在column里增加html标签,并给button添加事件呢? 1. ...

  9. C&num;获取本机所有用户名

    using System.DirectoryServices; using System.Runtime.InteropServices; (需要添加引用) [StructLayout(LayoutK ...

  10. 如何在vue里面访问php?

    如果你选择前端使用vue框架,后端用PHP开发,服务器就不用node了,用Apache就好了 开发中,看你是否想进行前后端的分离.如果你不想进行前后端的分离,可以将vue的项目build之后放到php ...