Difference between HTTP.SYS and WAS in IIS

HTTP.SYS (Hypertext Transfer Protocol Stack) is the kernel level components of IIS. All client request comes from client hit the HTTP.Sys of Kernel level. HTTP.SYS then makes a queue for each and every request for each and individual application pool based on the request.

Whenever we create any application pool IIS automatically registers the pool with HTTP.SYS to identify the particular during request processing.

WAS(Windows Activation Service) is a new feature of IIS, that allows all the features of the Windows Communication Framework stack, like non-HTTP channels and other stuff.

IIS is the web server that hosts the services that are activated via WAS.

WAS - is the new process activation mechanism that ships with IIS 7.0. WAS builds on the existing IIS 6.0 but is more powerful because it provides support for other protocols besides HTTP, such as TCP and Named Pipes.

For more details, go through IIS architecture

405 - HTTP verb used to access this page is not allowed

We get the above error when we use PUT verb when we access RESTFUL web services.

For this to work, The web site had to continue to enable WebDAV, but the web application needed to turn it off in order to support PUT and DELETE in its REST API.

Below are the approaches I followed to solve my problem.

Procedure 1:

1. In the IIS Manager, select the application that needs to support PUT.  
2. In the Features View, find WebDAV Authoring Rules.  Double-click it, or select Open Feature from the context menu (right-click).
3. In the Actions pane, find and click on WebDAV Settings....
4. In the WebDAV Settings, find Request Filtering Behavior, and under that, find Allow Verb Filtering.  Set Allow Verb Filtering to False.
5. In the Actions pane, click Apply.

Procedure 2:

1. Go to IIS Manager.
2. Click on your app.
3. Go to "Handler Mappings".
4. In the feature list, double click on "WebDAV".

5. Click on "Request Restrictions".
6. In the tab "Verbs" select "All verbs" .

7. Press OK.

Hope this helps!

How Application Pools Works ? (IIS 6.0)

What are Application pools? How it actually Works? The concept of Application Pools has from IIS 6.0. Application pools are used to separate sets of IIS worker processes that share the same configuration and application boundaries. Application pools used to isolate our web application for better security, reliability, and availability and performance and keep running with out impacting each other . The worker process serves as the process boundary that separates each application pool so that when one worker process or application is having an issue or recycles, other applications or worker processes are not affected. One Application Pool can have multiple worker process.

When you run IIS 6.0 in worker process isolation mode, you can separate different Web applications and Web sites into groups known as Application pools. An Application pool is a group of one or more URLs that are served by a worker process or set of worker processes. Any Web directory or virtual directory can be assigned to an application pool. Each application pool is given its own set of server resources. That way, if a Web site crashes, it won’t effect sites in other application pools.

A classic example of this is a Web site with a memory leak. If all of the Web sites hosted on a particular server were to share system resources, and one of the Web sites had a memory leak, it could potentially take memory away from the other hosted sites. If the leaky site were in its own application pool though, the memory leak would not effect any other site because each application pool has its own server resources (including memory).

Main idea behind application pools are
1. Isolation of Different Web Application
2. Individual worker process for different web application
3. More reliably web application
4. Better Performance

For more information check this URL from MSDN.

Hope this is useful