I'm developing an HttpModule. Some of its events are not called and I think it's because other HttpModules that are installed are ending the request or something similar.
Is it possible to configure IIS to produce a log of all the HttpModule requests in their order?
e.g.:
HttpModule1 BeginRequest called.
HttpModule2 BeginRequest called.
So I would know which methods are called on each HttpModule? (and try to identify why & where the request is ended)
NOTE: I don't control all the modules, so I can't just add logging in all of them...
Related
What's the difference between an Interceptor, Filter and Middleware in Nest.js framework? When should one of them be used and favored over the other?
Thanks
As you already implied with your question, all three are very similar concepts and in a lot of cases it is hard to decide and comes down to your preferences. But I can give an overview of the differences:
Interceptors
Interceptors have access to response/request before and after the route handler is called.
Registration
Directly in the controller class with #UseInterceptors() controller- or method-scoped
Globally with app.useGlobalInterceptors() in main.ts
Examples
LoggingInterceptor: Request before route handler and afterwards its result. Meassure time it takes.
ResultMapping: Transform null to [] or wrap result in a response object: users -> {users: users}
Conclusion
I like that the registration is closer to the route handlers compared to middleware. But there are some limitations, for example, you cannot set the response code or alter the response with Interceptors when you send the response with the library-specific #Res() object in your route handler, see docs.
Middleware
Middleware is called only before the route handler is called. You have access to the response object, but you don't have the result of the route handler. They are basically express middleware functions.
Registration
In the module, very flexible way of choosing relevant routes (with wildcards, by method,...)
Globally with app.use() in main.ts
Examples
FrontendMiddleware: redirect all routes except API to index.html, see this thread
You can use any express middleware that is out there. There are lots of libraries, e.g. body-parser or morgan
Conclusion
The registration of middleware is very flexible, for example: apply to all routes but one etc. But since they are registered in the module, you might not realize it applies to your controller when you're looking at its methods. It's also great that you can make use of all the express middleware libraries that are out there.
Exception Filters
Exception Filters are called after the route handler and after the interceptors. They are the last place to make changes before a response goes out.
Registration
Directly in the controller class with #UseFilters() controller- or method-scoped
Globally app.useGlobalFilters() in your main.ts
Examples
UnauthorizedFilter: Map to an easy to understand message for the user
NotFoundFilter: Map all routes that are not found (not part of your api) to your index.html.
Conclusion
The basic use case for exception filters are giving understandable error messages (hiding technical details). But there are also other creative ways of usage: When you serve a single page application, then typically all routes should redirect to index.html except the routes of your API. Here, you can redirect on a NotFoundException. Some might find this clever others hacky. Your choice. ;-)
So the execution order is:
Middleware -> Interceptors -> Route Handler -> Interceptors -> Exception Filter (if exception is thrown)
With all three of them, you can inject other dependencies (like services,...) in their constructor.
For those of us who "get it" better visually, I've created this NestJs pipeline digram based on the latest v6.10 version. Please feel free to point out any inaccuracies. I'll review and update it promptly, if needed.
I'm assuming that you mean Pipes instead of Filters as Filters are primarily tied to Exception Handling.
There is definitely some overlap as Middleware are a flexible way of composing any web application but are more of a generic concept (creating a stack of functions to build a pipeline). The others are Nest specific concepts and as such tie in a bit more naturally with things like Dependency Injection.
Pipes are used to transform input data (and optionally to do validation).
Interceptors are really neat because they can transform both data coming in and leaving your API. They give you the ability to mutate what the original handler would have returned through the use of observable streams. This is something that you would probably need to implement using two middlewares (on either side of the handler).
Use Pipes when you want to transform data coming in to a handler.
Use Interceptors when bi-directional transformation is required.
Use middlewares when you want to stick closer to the traditional (eg Express) way of building your web app or when you want to more broadly apply functionality to many handlers at once (there's less decorators floating around in your code).
Middleware
The usage and function of the middleware of Nest.js is basically equivalent to Express.js, which generally functions for:
execute any code.
make changes to the request and the response objects.
end the request-response cycle.
call the next middleware function in the stack.
if the current middleware function does not end the request-response
cycle, it must call next() to pass control to the next middleware
function. Otherwise, the request will be left hanging.
Interceptor
The interceptor can transform data between the controller and the client-side, which can perform functions for:
bind extra logic before / after method execution
transform the result returned from a function
transform the exception thrown from a function
extend the basic function behavior
completely override a function depending on specific conditions
(e.g., for caching purposes)
Filter
In Nest.js, the Filter generally refers to the Exception filter, which is responsible for processing all unhandled exceptions across an application:
a built-in global exception filter handles exceptions of type HttpException (and subclasses of it)
custom exception filters are designed for controlling the exact flow of control and the content of the response sent back to the client. For example, add logging or use a different JSON schema based on some dynamic factors.
I am developing a grails application and am pretty new to grails at all. Right now I got stuck in implementing a listener that needs to render a view whenever it's called (Concrete: It is a listener for incoming xmpp messages of the Smack Library). I implemented this listener in a service which works fine so far, but now I need to render a view, when the listener gets called. So I tried to access the session or the controller on many different ways from inside of the listener, but all approaches lead to this error message:
No thread-bound request found: Are you referring to request attributes
outside of an actual web request , or processing a request outside the
originally receiving thread? If you are actually operating within a
web request and still receive this message, your code is probably
running outside of DispatcherServlet/DispatcherPortlet. In this case
use RequestContextListener or RequestContextFilter to expose the
current request.
In other code blocks of my service I was able to access the session, but not within my listener object:
def webRequest = RequestContextHolder.currentRequestAttributes()
webRequest.getSession()
Can anybody help me out here? Can I solve this using the RequestContextListener or RequestContextFilter like described in the error message and if yes, how do I do that? Or is there any other way to access the controller or the session from inside my listener?
Another approach would be to implemented this listener within the controller, but will this work and will I be able to access the session this way? Or will it also be a "no thread-bound request"?
Thank you very much for your answers in advance!
I am using IIS to develop some web applications. I used to believe that every application should have a entry point. But it seems a web application doesn't have one.
I have read many books and articles addressing how to build an ASP.NET application under IIS, but they are just not addressing the most obvious and basic thing that I want to know.
So could anyone tell me how is a web application started? What's the difference between a traditional desktop application and a web application in terms of their working paradigm, such as the starting and terminating logic.
Many thanks.
Update - 1 - 23:14 2011/1/4
My current understanding is:
When some request arrives, the URL contained in the request will be extracted by the IIS. I guess IIS must have maintained some kind of a internal table which maps a URL to corresponding physical directory on disk. Let's take the following URL as an example:
http://myhost/webapp/page1.aspx
With the help of the aforementioned internal table, IIS will locate the page1.aspx file on disk. And then this file is checked and the code-behind code file is located. And then proper page class instance will be contructed and its methods defined in the code-behind file will be invoked in a pre-defined order. The output of the series of method invoking will be the response sent to the client.
Update - 2 - 23:32 2011/1/4
The URL is nothing but an identifier that serves as an index into the aforementioned internal table. With this index, IIS (or any kind of web server technology) could find the physical location of the resource. Then with some hint (such as file extension name like *.aspx), the web server knows what handler (such as the asp.net ISAPI handler) should be used to process that resource. That chosen handler will know how to parse and execute the resource file.
So this also explains why a web server should be extensible.
It depends what language and framework you are using, but broadly there are a number of entry points that will be bound to HTTP requests (e.g. by URL). When the server receives a request that matches one of these bindings, the bound code is executed.
There may also be various filter chains and interceptors that are executed based on other conditions of the request. There will probably also be some set-up code that the server executes when it starts up. Ultimately, there is still a single entry-point - the main() function of the server - but from the web application's perspective it is the request bindings that matter.
Edit in response to question edits
I have never used IIS, but I would assume there is no "lookup table", but instead some lookup rules. I shall talk you through the invocation of a .jsp page on an Apache server, which should be basically the same process.
The webapp is written and placed in the file system - e.g. C:/www/mywebapp
The web server is given a configuration rule telling it that the URL path /webapp/ should be mapped to C:/www/mywebapp
The web server is also configured to recognise .jsp files as being JSP servlets
The web server receives a request for /webapp/page1.jsp, this is dispatched to a worker thread
The web server uses its mapping rules to locate C:/www/mywebapp/page1.jsp
The web server wraps the code in the JSP file in a class with method serveRequest(request, response) and compiles it (if not already done so)
The web server calls the serveRequest function, which is now the entry point of the user code
When the user code is finished, the web server sends the response to the client, and the worker thread terminates
This is the most basic system - resource-based servlets (i.e. .jsp or .aspx files). The binding rules become much more complicated when using technologies like MVC frameworks, but the essential concepts are the same.
Similar to what OrangeDog mentioned in his answer, there is plenty that goes on when serving these pages Before you even get to your code.
Not only in asp.net mvc, but in asp.net in general there are various pieces that come into play when you're executing a request.
There is code like modules, handlers, etc that again do processing Before it gets to the code of the page. Additionally you can map the same page to be able to process different urls.
The concept of handler in asp.net is important, as there are various handlers that are responsible of processing requests that match extensions and/or http verbs (get, head, post). If you take a look into %systemroot%\Microsoft.NET\Framework64\v4.0.30319\Config\web.config, you can see a section. You can also see the handlers in IIS (these can be changed x site).
For example, the HttpForbiddenHandler is one that just rejects the request. It is configured to be called for special files like the sources "*.cs".
You can define your own handler, that is nothing more than a class that implements an IHttpHandler interface. So it has 2 methods: ProcessRequest and IsReusable. This is more similar to your cgi program, as the implementation is mainly a method that produces HTML or any other type of output based on the information in the request.
Asp.net pages build on top of that, and have plenty of extra features meant to make it easier for you to develop pages. You implement a class that inherits from Page, and there are 2 code files associated to it (.aspx and .cs). The same can be said for asp.net mvc, but it is structured differently. There is much more than it, if you want to take advantage of it you'd need to learn about it.
The downside of those abstractions, is that it makes some developers lose track of the context they're at / about the underlying. The context is still the same, you're producing an application that takes a request and produces an output. The difference is that there is plenty more code in place intended to make it easier.
In terms of a more detailed list of IIS's ASP.NET Request Lifecycle, there are a quite a few stages in the HTTPApplication Pipeline. Faily recently there was a good blog post that I thought summarized them very concisely and well. It's "HTTP Request Lifecycle Events in IIS Pipeline that every ASP.NET Developer Should Know" by Suprotim Agarwal.
For a more detailed explanation you should check out the MSDN article on the subject. This will also go into information on what happens before that pipeline.
In ASP.NET there is the Application_EndRequest event in global.asax. In classic ASP however there is no such equivalent event in global.asa
Is there any other built in way of handling the end request event, or any way of somehow hooking into IIS to accomplish the same thing?
We use a particularly twisted technique to execute code after the request has completed. Consider the following snippet:
Class EndRequestHandler
Sub Class_Terminate()
'' Handler code goes here
End Sub
End Class
Set EndRequestHandlerInstance = New EndRequestHandler
When the request ends, ASP unloads all of the global variables, including EndRequestHandlerInstance, which calls it's Class_Terminate method. If you place this into an include file that's used by every page on the site, it should serve as your global end request handler.
On IIS6 and older (or in an IIS7 classic pipeline application pool) you would really need to the help of an ISAPI filter to achieve the same sort of thing as a global End Request opertaion.
In IIS7 integrated pipeline you could use .NET End Request code even if the page executed is a classic ASP.
Not being nosy but what is it that you are trying to do? There might be different solutions for what you want (such as rendering out debug goodies at the footer of each page) or no solutions at all (such as my wish that I could get the contents of the Response buffer and mess with it before farming it out to the wire)
I have a WCF Client Proxy connected to a third party webservice.
The proxy works fine with nearly everything except on function.
This function works just fine with a ASMX proxy.
I have added service trace logging and can see the response from the service coming back.
Only the proxy returns null.
So now I know for sure that the proxy is at fault.
Where to from here?
RESOLUTION
I found the issue. WCF is less forgiving than an ASMX proxy.
The service WSDL specifies that the returned object was called "data", and the actual xml passed back was called "result"
So that was a great goose chase! I think i wasted 4 hours on this problem!
You can try to use Trace Viewer to analyse WCF communications in more detail and find out more detail when errors are encountered.
Within the app.config (Client) and web.config (Server), you can add blocks. To enable tracing, simply add dignostics blocks and trace files will be generated in the specified location when the app is run. This should enable you to dig a little deeper with the problem.
Trace viewer can be found:
("C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcTraceViewer.exe")
Info on trace viewer usage:
http://msdn.microsoft.com/en-us/library/aa751795.aspx
Also, what type of method is it? does it return complex types or simple types?
ADDED:
Ah, sorry about the mis-read, didn't realise you had no control of server side. I'd try to update the service reference/proxy (you've probably already done that) and check if anything has changed.
WCF doesn't make tracking down issues very easy i'm afraid. Is it possible to provide the method signatures for a call that works and one that doesn't so we can see what data types are being passed about?