Develop Reference

ServiceStack order of operations problem during the execution of a Service

We are upgrading our classic ASP.NET application for ServiceStack v5.11.0 from v3.9.64 and are eager to become a paying customer of ServiceStack. But we must resolve this problem. The lifecycle and order of operations has changed in ServiceStack. There are certain points in the lifecycle of a request as handled by ServiceStack where HttpContext.Current is not yet populated. All of our code expects that to be set up, so we must avoid that in our processing or a request. Below is the order of operations that we think we need.
First, HttpContext.Current must be populated by the system.
Next, we need an event to fire on our AppHost : AppHostBase that allows us to initialize our middle tier. We are currently trying AppHost.OnPreExecuteServiceFilter, but this is proving problematic due to the invocation of Plugins. Please read on.
Next, we have a Plugin we have written to do authentication that is added to Plugins in AppHost.Configure. We need this to be invoked AFTER Step 2.
Then we want our Service code to be invoked.
Finally, we need AppHost.OnEndRequest to be invoked.
The problem we face above is that our authentication Plugin is being invoked BEFORE AppHost.OnPreExecuteServiceFilter, and so our code fails because we have not initialized our middle tier yet. So Step 2 and 3 are occurring in the wrong order currently. How do we fix this? Is there a different AppHost event that is fired after HttpContext.Current is populated, and before Plugins are invoked? Or can we configure our plugin to be invoked just after AppHost.OnPreExecuteServiceFilter?
Further notes on this. With v3.9.64 our Global.Application_BeginRequest and EndRequest events were being used for the above purpose, and that was always working fine. I do see that these events are fired upon an incoming ServiceStack request, but they are not happening in the same order they used to, thus we face this problem.

The Order of Operations is simply the order in which different hooks and filters are executed within a ServiceStack Request.
OnPreExecuteServiceFilter is as the name says a filter that's executed just before a Service is executed.
Next, we have a Plugin we have written to do authentication that is added to Plugins in AppHost.Configure. We need this to be invoked AFTER Step 2.
AppHost.Configure() is executed only once on Startup for the purposes of configuring your AppHost. If you want your Plugin to execute logic during a request it needs to register a Custom Filter that's executed within the ServiceStack Request Pipeline.
The problem we face above is that our authentication Plugin is being invoked BEFORE AppHost.OnPreExecuteServiceFilter
This method is executed before a Service is executed, the only other filters executed after this method but before a Service are Service Filters and Action Request Filter attributes.
Is there a different AppHost event that is fired after HttpContext.Current is populated
HttpContext.Current is populated by the ASP.NET Framework before any ServiceStack Request is executed which means it's always populated before any of the filters in a ServiceStack Request pipeline. The major Reason why it wouldn't be populated is if it was not accessed from an ASP.NET Request Worker Thread during a Request at runtime.
and before Plugins are invoked?
This is impossible to answer as your question leaves out the vital information as to where exactly your plugin registers its custom handlers? i.e. What filters are executed before then is dependent on what request filter your plugin is registering. The order of which different handlers are executed during a request is documented in our Order of Operations page.
If you're referring to your plugins Register(IAppHost), this like AppHost.Configure() is only executed once on Startup, you cannot access HttpContext.Current on Startup, it's only available during a Request. The Startup initialization logic is where your plugin would register its Request filters, e.g. appHost.PreRequestFilters or appHost.GlobalRequestFilters which are executed during a request before a ServiceStack Service is executed. Whereas the *ResponseFilters are executed after a Service is executed.
Now HttpContext.Current is for accessing an ASP.NET Request Context from a singleton context for when the Request context is not available however this is generally unnecessary in ServiceStack as every Request Filter can retrieve the ASP.NET Request Context from a ServiceStack IRequest.OriginalRequest, e.g:
PreRequestFilters.Add((req, res) =>
{
var aspReq = req.OriginalRequest as HttpRequestBase;
});
E,g. within a Service you can access IRequest from base.Request.

How do I add an event handler for every request in ASP.NET that will be handled by PageHandlerFactory

I want to configure an asp.net website so that for every request it executes my event handler(say for tracking/logging some info from request object) only if request will be handled by an PageHandlerFactory.
I know I can write it in Application_BeginRequest but that is called for every kind of request(be it *.axd or so ,Correct me if I'm wrong here). HttpContext.Current.CurrentHandler might be null at this time so I can't put conditional logic for handler type. For some reason(legacy business rules/checks) I can't move the my logic to Application_EndRequest.

Use can try using the httphandler and httpmodule in asp.net
it has an event LogRequest
LogRequest - Occurs just before ASP.NET performs any logging for
the current request. The LogRequest event is raised even if an error
occurs. You can provide an event handler for the LogRequest event to
provide custom logging for the request.
Furthure in ASP.net we have
ASP.NET uses different HTTP handlers to serve different file types.
For example, the handler for web Page creates the page and control
objects, runs your code, and renders the final HTML. ASP.NET default
handlers:
1) Page Handler (.aspx) – Handles Web pages 2) User Control Handler
(.ascx) – Handles Web user control pages 3) Web Service Handler
(.asmx) – Handles Web service pages 4) Trace Handler (trace.axd) –
Handles trace functionality
You can get more insight at
httphandler and httpmodule in asp.net

When HttpModule Init method runs in ASP.NET Integrated mode?

I've written an HttpModule that is an NHibernate Session Provider. It simply opens a SessionFactory in Init method of HttpModule and gets a new Session in BeginRequest and closes it in EndRequest. At the other side, I wrote a method in Global.asax that uses a session from this HttpModule named GetData. I run that method (GetData) in Init method of Global.asax. The problem is when I use my HttpModule in integrated mode it seems that my HttpModule does not Initialize before running Init method of Global.asax.
I've searched for order of running these methods and life cycle of events but nothing useful found!

In IIS 7.x, modules and handlers should be registered within system.webServer xml element in your web.config file.
Check this MSDN article:
http://msdn.microsoft.com/en-us/library/ms227673.aspx

ASP.NET does not provide any guarantees on when HttpModule Init() methods are called with respect to one another (not unlike static initializers). In general, the Init() methods should be used to wire up event handlers, and any "real work" should be done in the event handlers.
All registered event handlers for a specific event are called from all HttpModules, including Global.asax, before moving on to the next event -- so you have control over order that way.

Confused over global.asax?

I have a class called Global that derives from HttpApplication.
Oddly, I see a lot of methods inside Global that look like:
void Application_Start(object sender, EventArgs e)
{
}
The code is definitely executing inside this method, so the method is being called from somewhere, but where? The methods aren't marked overload?
Secondly, I derived a class from Global, let's call it GlobalFoo.
Again, if I create a method called Application_Start() it will get called inside my derived class, otherwise nothing that's in Global will get called so I might as well be deriving from an empty class.
Can anyone offer any advice? Am I missing some fundamental part of ASP.NET?

so the method is being called from somewhere, but where?
This functions are called from the Application Pool (from each pool that you have assign), to signal start-up/end events of your application and help your with initializations.
Every pool that is assign to run your web application runs those functions.
asp.net is helping you create different objects/code external or not that can run together, and that's why you see that all of your registered code run. Its a help to create more than one "start up" routines that do different thinks.
This is an example, this module just check the secure protocol by him self... and you do not need to change anything on your code, just register it.

IIS calls the different Global.asax events through the asp.net isapi filter.
Perhaps this article will help explain.

The Global.asax file is an optional file used to declare and handle application and session-level events and objects for an ASP.NET web site running on an IIS Web Server
some of the key events in this file are:
Application_Init: Fires when the application initializes for the first time.
Application_Start: Fires the first time an application starts.
Session_Start: Fires the first time when a user’s session is started.
Application_BeginRequest: Fires each time a new request comes in.
Application_EndRequest: Fires when the application terminates.
Application_AuthenticateRequest: Indicates that a request is ready to be authenticated.
Application_Error: Fires when an unhandled error occurs within the application.
Session_End: Fires whenever a single user Session ends or times out.
Application_End: Fires when the application ends or times out (Typically used for application cleanup logic).
For a complete list of Global.asax events see "Global.asax Events".

IHttpHandler vs IHttpModule

My question is simple (although the answer will most likely not be): I'm trying to decide how to implement a server side upload handler in C# / ASP.NET.
I've used both HttpModules (IHttpModule interface) and HttpHandlers (IHttpHandler interface) and it occurs to me that I could implement this using either mechanism. It also occurs to me that I don't understand the differences between the two.
So my question is this: In what cases would I choose to use IHttpHandler instead of IHttpModule (and vice/versa)?
Is one executed much higher in the pipeline? Is one much easier to configure in certain situations? Does one not work well with medium security?

An ASP.NET HTTP handler is the process (frequently referred to as the "endpoint") that runs in response to a request made to an ASP.NET Web application. The most common handler is an ASP.NET page handler that processes .aspx files. When users request an .aspx file, the request is processed by the page through the page handler. You can create your own HTTP handlers that render custom output to the browser.
Typical uses for custom HTTP handlers include the following:
RSS feeds To create an RSS feed for a Web site, you can create a handler that emits RSS-formatted XML. You can then bind a file name extension such as .rss to the custom handler. When users send a request to your site that ends in .rss, ASP.NET calls your handler to process the request.
Image server If you want a Web application to serve images in a variety of sizes, you can write a custom handler to resize images and then send them to the user as the handler's response.
An HTTP module is an assembly that is called on every request that is made to your application. HTTP modules are called as part of the ASP.NET request pipeline and have access to life-cycle events throughout the request. HTTP modules let you examine incoming and outgoing requests and take action based on the request.
Typical uses for HTTP modules include the following:
Security Because you can examine incoming requests, an HTTP module can perform custom authentication or other security checks before the requested page, XML Web service, or handler is called. In Internet Information Services (IIS) 7.0 running in Integrated mode, you can extend forms authentication to all content types in an application.
Statistics and logging Because HTTP modules are called on every request, you can gather request statistics and log information in a centralized module, instead of in individual pages.
Custom headers or footers Because you can modify the outgoing response, you can insert content such as custom header information into every page or XML Web service response.
From: http://msdn.microsoft.com/en-us/library/bb398986.aspx

As stated here, HttpModules are simple classes that can plug themselves into the request processing pipeline, whereas HttpHandlers differ from HttpModules not only because of their positions in the request processing pipeline, but also because they must be mapped to a specific file extensions.

IHttpModule gives you much more control, you can basically control all of the traffic directed to your Web application. IHttpHandler gives you less control (the traffic is filtered before it reaches your handler), but if this is sufficient for your needs, then I see no reason to use the IHttpModule.
Anyway, it's probably best to have your custom logic in a separate class, and then just use this class from either IHttpModule or IHttpHandler. This way you don't really have to worry about choosing one or the other. In fact, you could create an extra class which implements both IHttpHandler and IHttpModule and then decide what to use by setting it in Web.config.

15 seconds has a nice small tutorial giving practical example

Modules are intended to handle events raised by the application before and after the request is actually processed by the handler. Handlers, on the other hand, aren't given the opportunity to subscribe to any application events and, instead, simply get their ProcessRequest method invoked in order to the "main" work of processing a specific request.
Take a look at this documentation from Microsoft (about half way down the page in the "The request is processed by the HttpApplication pipeline" section):
http://msdn.microsoft.com/en-us/library/bb470252.aspx
You can see in step 15 where the handler gets its chance to execute. All of the events before and after that step are available for interception by modules, but not handlers.
Depending on what specific features you're trying to achieve, you could use either a handler or a module to implement an upload handler. You might even end up using both.
Something to consider might to use an upload handler that's already written.
Here's a free and open source one:
http://www.brettle.com/neatupload
Here's a commercial one:
http://krystalware.com/Products/SlickUpload/
If you look at the documentation for NeatUpload, you'll see that it requires you to configure a module.