Demonstrating this particular demo will have to include the CompleteRequest() call, which is still important to 'warn' about. Moral of the story for me: I better double check my demos more carefully under 2.0. So it seems odd that the Response.End() call is in fact firing the rest of the events. And the second path calls HttpApplication.CompleteRequest() which as shown above does bypass the pipeline (except for the HttpApplication.EndRequest event which is guaranteed to fire). In both of the conditional paths it seems like the Pipeline is in fact short circuited – Thread.Abort() certainly will cause an exception in the application (unless the CancelModuleException holds some significance here) and terminate the request. Looking at this code I'm actually not sure what ASP.NET is doing to keep the processing of the Pipeline alive. If ( this._context.ApplicationInstance != null) ( new HttpApplication.CancelModuleException( false)) If ( this._context.IsInCancellablePeriod) But, curious person that I am I wanted to check out what ASP.NET is doing differently here so I dug out Reflector and checked out Response.End: It looks like this is what Response.End() does now.
There maybe other things happening too - compression of output, special formatting - who knows what that should still happen even though the Response has effectively been killed. As in this scenario I would much prefer to have the pipeline continue processing and put my footer on the page even though I issued a Response.End(). This is a good thing because in most situations you don't actually want the short circuiting to happen. It looks like there's a definite (and welcome) behavior change in ASP.NET that causes Response.End() no longer to short circuit the Http Pipeline. Now the short circuiting does happen as before. Now I can still force the pipeline to short-circuit, but I have to explicitly call on the HttpApplicationInstance and CompleteRequest:
There's a checkbox on the form and when checked Response.End() is called.īut alas in ASP.NET 2.0 when I call it, the HTML content added by the module that adds a footer to the page continues to display just fine. Protected void Page_Load( object sender, System. The trivial code I use for the sample is something like this: It was supposed to short circuit and NOT show the footer, but in good Murphy's Law tradition it of course showed the footer… Ooops. So I have one demo that shows some page logic that calls Response.End(), while I have an HTTP Module hooked up that adds a footer to every page.
In the past I've always stressed one thing to be aware of in that ASP.NET can shortcircuit the pipeline if HttpApplication.CompleteRequest() and Response.End() (which used to implicitly call HttpApplication.CompleteRequest). The events off the HttpApplication object are essentially what drives the pipeline with both direct event hookups and HttpModules that hook into these events via Web.Config and the IHttpModule interface. In discussion of the ASP.NET pipeline firing off the HttpApplication events, I ran into a somewhat embarrassing snag that I apparently hadn't checked out recently in one of my demos. Īnyway, it talks about low level aspects of ASP.NET up to the HttpHandler level. I like doing this session – it's one of those that I don't get to do often and it's one of those deep topics that are fun to get wrapped up in for an hour or so. RUN adduser -disabled-password -gecos "" -force-badname -ingroup mfrgroup mfruserĪnd started docker container with docker-compose file version: '3.7'Ĭommand: hugo server -watch=true -bind 0.0.0.0Įverything is fine except hugo don’t catch changes on file system by live-reload.I'm at DevTeach this week and yesterday I ran my Low Level ASP.NET Session here. I created Docker image with the following Dockerfile FROM ubuntu:19.04ĮNV HUGO_BINARY hugo_extended_$ I tried the following configuration under Ubuntu 18.04.1 LTS (on Hyper-V) and don’t have this problem so configuration looks good for me. It doesn’t catch any changes on file system.
I have a problem with live-reload under Windows 10 and Docker.
0 kommentar(er)
