Sukesh's IIS Blog : HTTP & IIS

Redirecting from http to https in IIS7 (http2https Updated)

sukesh — Wed, 05 Sep 2007 07:07:00 GMT

I had written a sample to redirect all http traffic to https (secure) in September 2006 http://www.awesomeideas.net/post/2006/09/03/Redirecting-from-http-to-https-in-IIS7.aspx

In one of our internal discussion alias the question came up that this method does not work when SSL is forced on the website. Step 5 below handles that scenario by checking the "403.4 SSL required" response and handling it during OnEndRequest event.

So let us get into action (I'm using C# for this sample)

Download and Install IIS7 Managed Module Starter Kit
(Not really a requirement but it would make developing IIS7 modules easier)
Rename the default class name created to "redir.cs" and rename project/solution/namespace to "http2https"

Add the following code in "Init" method

// register for the BeginRequest event
application.BeginRequest += new EventHandler(OnBeginRequest); 
application.EndRequest += new EventHandler(OnEndRequest);

Add the following method to implement "BeginRequest" event

//BeginRequest implementation
public void OnBeginRequest(Object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
string HttpUrl = app.Request.Url.ToString(); 

   if (HttpUrl.StartsWith("http:"))                           //Redirection done only if URL starts with http:
   {
   HttpUrl = HttpUrl.Replace("http:", "https:");
   app.Response.Redirect(HttpUrl.ToString(), true);           //Redirecting (http 302) to the same URL but with https
   app.Response.End();                                        //We don't want to any further so end
   }
}

Add the following method to implement "OnEndRequest" event

//This is for scenario where SSL is forced on the site
public void OnEndRequest(Object sender, EventArgs e)
{
  HttpApplication app = (HttpApplication)sender;
  if (app.Response.StatusCode == 403 && app.Response.SubStatusCode == 4)
  { 
    string HttpUrl = app.Request.Url.ToString();

    if (HttpUrl.StartsWith("http:"))
    {
        HttpUrl = HttpUrl.Replace("http:", "https:");
        app.Response.Redirect(HttpUrl.ToString(), true);
        app.Response.End();
    }
}

Make sure you have the following in your web.config inside configuration tag

<system.webServer>
<modules>
   <add name="redir" type="http2https.redir" />
</modules>
</system.webServer>

Your http to https redirection sample is ready and also works if you force SSL!!!

How to deploy the HttpModule
There are multiple ways you can deploy this component (I'm assuming that it's being deployed for "default website")

Method 1
Create a folder called "App_Code" inside "%systemdrive%\inetpub\wwwroot"
Copy "redir.cs" file into "App_Code" folder
Copy "web.config" file inside "%systemdrive%\inetpub\wwwroot"

Method 2
Create a folder called "bin" inside "%systemdrive%\inetpub\wwwroot"
Compile "redir.cs" into "redir.dll" and copy it into "bin" folder (to compile -> csc.exe /out:redir.dll /target:library redir.cs)
Copy "web.config" file inside "%systemdrive%\inetpub\wwwroot"

If you open IIS7 UI and go to Modules you can see your HttpModule listed there.

Source code @ http://www.awesomeideas.net/page/IIS7-http2https.aspx

Redirecting from http to https in IIS7

sukesh — Sun, 03 Sep 2006 18:22:00 GMT

I was thinking to write an HttpModule for IIS7 and wanted a simple, useful and easily understandable scenario. Working with IIS customers for last 3 years one of those common scenario came into my mind, Redirecting http traffic to https. Although this is pretty straight forward requirement, till IIS6 it was difficult to achieve. Check the following KB 839357 (specifically for OWA scenario) which explains the cumbersome steps .

(If you are looking for same functionality in prior versions of IIS, find it at the bottom of this post)

HttpModules are not something new if you are an ASP.NET developer. But there are some differences. In IIS7 because of integrated pipeline, HttpModule applies to any request not just ASP.NET and that includes htm,jpg,asp,aspx,asmx,php,jsp...

So let us get into action (I'm using C# for this sample)

Download and Install IIS7 Managed Module Starter Kit
(Not really a requirement but it would make developing IIS7 modules easier)
Rename the default class name created to "redir.cs" and rename project/solution/namespace to "http2https"
Add the following code in "Init" method
// register for the BeginRequest event
application.BeginRequest += new EventHandler(OnBeginRequest);
Add the following method to implement "BeginRequest" event
//BeginRequest implementation
public void OnBeginRequest(Object sender, EventArgs e)
{
HttpApplication app = (HttpApplication)sender;
string HttpUrl = app.Request.Url.ToString();
if (HttpUrl.StartsWith("http:"))                                       //Redirection done only if URL starts with http:
{
   HttpUrl = HttpUrl.Replace("http:", "https:");
   app.Response.Redirect(HttpUrl.ToString(), true);      //Redirecting (http 302) to the same URL but with https
   app.Response.End();                                                   //We don't want to any further so end
}
}
Make sure you have the following in your web.config inside configuration tag
<system.webServer>
<modules>
<add name="redir" type="http2https.redir" />
</modules>
</system.webServer>

Your http to https redirection sample is ready!!!

How to deploy the HttpModule
There are multiple ways you can deploy this component (I'm assuming that it's being deployed for "default website")

Method 1
Create a folder called "App_Code" inside "%systemdrive%\inetpub\wwwroot"
Copy "redir.cs" file into "App_Code" folder
Copy "web.config" file inside "%systemdrive%\inetpub\wwwroot"

If you open IIS7 UI and go to Modules you can see your HttpModule listed there.

Redirection options for prior versions of IIS below (you need to search for these)

- ASP.NET URL mapping capability (HttpContext.RewritePath)
- IIS v6.0 Resource Kit includes the UrlRemap tool
- IISRewrite
- ISAPI_Rewrite - includes a "lite" version available for free.
- Mod_Rewrite 2
- Ionic's ISAPI Rewrite Filter

Back to Basics - HTTP/IIS (Part II)

sukesh — Tue, 16 May 2006 21:17:00 GMT

Let us see how HTTP is extended to do more than serving static content.

When we talk about Windows Platform & HTTP, Microsoft product which comes to the picture is IIS. In the early days (and early versions of IIS) HTTP was primarily used for hosting websites and to enable people to use browsers to request those websites. So in essence IIS (or for that matter any web server) is built to serve “static” HTML pages with resources like images (referring to IIS2). But later versions of IIS provided ways to extend the web server in order to provide dynamically serving websites. In IIS world we call it as ISAPI Extensions. Hmmm... So what is ISAPI Filters then?

Let’s try to understand more about ISAPI Filters, ISAPI Extensions & Wildcard ISAPI Extensions to get more clarity.

ISAPI Filters

From the name itself you know that it’s something to do with filtering. Yea you got it right! So IIS exposes a set of notifications (IIS term for events) so that we can develop an ISAPI Filter (dll with a difference) to register for these notifications. When IIS triggers these notifications your ISAPI Filter DLL gets a chance to handle the data available for that specific notification.

Confused? Huh! Let me try with a hypothetical example then,

Assume that you have an ASP application and you don’t want your web users to know that it’s really ASP. So what can you do? Let them request .ASPX pages and we will change the extension to .ASP before IIS gets it for further processing. Good Idea?

Change all your links in the site to point to .ASPX extension. And when web users request “default.aspx” the ISAPI Filter would change the file requested to “default.asp” without the user’s knowledge and show off that you are running an ASP.NET application but under the hood it’s a legacy ASP application. J

How does this work or how is this implemented?

Like I mentioned before you need to use one of those ISAPI Filter notification called SF_NOTIFY_PREPROC (search on MSDN for more information). So what does that give us? When a request enters IIS and when IIS reads in the HTTP request header our ISAPI Filter gets a chance to access HTTP request header and if required we can modify it. So in our scenario, we would see that URL field in the header contains “default.aspx”. Yes you guessed it, we would change that URL to “default.asp” and let IIS know that it needs further processing. Cool deal hah!

Important piece of code from the ISAPI source provided below to show how easy it is

Char buffer[256];

DWORD buffSize = sizeof(buffer);

BOOL bHeader = pHeaderInfo->GetHeader(pCtxt->m_pFC,"url",buffer,&buffSize);

CString urlString(buffer);

urlString.MakeLower();

if (urlString.Find(".aspx”) != -1) //we want to change this file’s extension

{

urlString.Replace(".aspx",".asp");

char *newUrlString= urlString.GetBuffer(urlString.GetLength());

pHeaderInfo->SetHeader(pCtxt->m_pFC, "url", newUrlString);

//we’re done, now give it to IIS for further processing

return SF_STATUS_REQ_HANDLED_NOTIFICATION;

}

ISAPI Extensions

So like I mentioned before a web server serves static pages, the dynamic features like ASP, ASP.NET, PHP etc happens because of ISAPI extensions. So the obvious is that ISAPI Extensions are a way to extend the Web Server to add more features to it.

So once the requests surpass the ISAPI Filter and if the request is not for static page, IIS searches for an ISAPI extension which is mapped to the request file extension. If found the request is forwarded to that ISAPI Extension for further processing and returning a valid response back to the client.

Wildcard ISAPI Extensions (IIS6 specific)

Here we will talk about why we need this piece and what are we trying to achieve here. Yes you guessed it, Wildcard extensions comes in between ISAPI Filters & ISAPI Extensions, so that it can have the features of both ISAPI Filters & Extensions.

Request

IIS [ ISAPI Filter -> Wildcard Extension -> ISAPI Extension]

Response

Before getting into details lets see the Pros & Cons of ISAPI Filters & ISAPI Extensions.

ISAPI Filters

Pros of ISAPI Filters

Every request can be intercepted regardless of the file extension
Filter notification allows us to enhance or replace some of the IIS features
1. Custom Redirection or request filtering - SF_NOTIFY_PREPROC_HEADERS
2. Custom Authentication – SF_NOTIFY_AUTHENTICATION
3. Modify IIS log values – SF_NOTIFY_LOG
  etc… (notification list documented on MSDN)

Cons of ISAPI Filters

No Asynchronous support
Uses IIS thread pool and cannot implement its own thread pool, so whatever processing of request is being done inside the filter should be completed quickly, otherwise chances are that IIS runs out of worker threads and users starts seeing errors like “Server too busy” or IIS gets into a hung state without responding to requests.
No access to entity body (huh! its another term for HTTP request body)

ISAPI Extensions

Pros of ISAPI Extensions

Gets the entire entity body (HTTP request body)
Can implement custom thread pool
Processing the request can be asynchronous

Cons of ISAPI Extensions

Can handle only requests to specific extensions (because its mapped to specific file extension.
Processing happens only after getting the complete request entity body.

Wildcard ISAPI Extensions

Pros of ISAPI Wildcard Extensions (hybrid of Filter & Extension)

Every request can be intercepted regardless of the file extension

ISAPI Filters: Yes
ISAPI Extensions: No

Implement custom thread pool

ISAPI Filters: No
ISAPI Extensions: Yes

Asynchronous Processing

ISAPI Filters: No
ISAPI Extensions: Yes

Handle entire request processing and return response to the client or hand over to an ISAPI Extension (according to the extension) for further processing.

ISAPI Filters: Yes
ISAPI Extensions: Yes

Can get access to complete request entity body

ISAPI Filters: No
ISAPI Extensions: Yes

So from the above list you can see that Wildcard ISAPI Extension provides a way to get best of both worlds (ISAPI Filter & ISAPI Extension).

Back to Basics - HTTP (Part I)

sukesh — Sat, 06 May 2006 21:15:00 GMT

Most of my interactions in the past with customers, web developers and some of my prior colleagues, I have found that a larger percentage of them don't have a good understanding of how HTTP protocol works. This could be due to various reasons; some of them could be like

Coming from windows application development background.
Not getting enough time to go through the details due to project deadlines.
Too difficult to get the meat out of HTTP RFC document because it’s too much to read.

This results in lot of confusions and also leads to low performance application development. So I thought I would help the readers of putting those confusions to rest and explain all these in simple and effective way. So, in essence this article is no rocket science, but HTTP basics which most of those HTTP/IIS experts left out thinking that it would not be necessary to be explained (Or maybe its there but I missed noticing it).

Is HTTP a popular protocol, Oh really?

The popularity of HTTP protocol is simply because it's a simple protocol when you try to understand it from grass root level. Because of the simplicity (huh, I think due to recent developments people have made it a little complex) HTTP is used extensively not just for serving HTML pages but in order to empower several applications to make it work on the web.

How does a simple HTTP response look like?

#include <iostream.h>

#include <windows.h>

int main (int argc, char** argv,char **envp)

{

cout << "Content-Type: text/html\r\n\r\n"; //Header

cout << "<h2>Hello World!</h2>" <<endl; //Body

return 1;

}

How does HTTP works with authenticated request?

Browser send GET request to IIS (remember 1^st request is always anonymous)
IIS returns 401 and provides WWW-Authenticate Header with the supported authentication methods
According to authentication method Browser pop-up the dialog to enter credentials and then submits to IIS
Credentials gets validated and if valid, your GET request is served with HTTP Status 200 (200 = success)

Why do we need sessions in HTTP?

Since HTTP is a connection-less protocol we need to provide a way to continue request-response process without having to create a ‘fresh’ newer connection for every request.