I am finishing up on the series of ASP pages that show how to:

You know, the common programmatic stuff one wants to do on the web server to enable dynamic applications.

Yes, there is a good reason why I am going through this exercise with 10-year old ASP technology, and it has nothing to do with boredom. ;-) Hehe, it is always nice to have good debugging code on the server...

Where I am going with this is that later on, I am going to illustrate how IIS7 extensibility truly integrates native and managed modules. Yes, they ALL can finally modify and share the same request and response headers AS WELL AS Server Variables.

For years, you all have been asking for a way to modify AUTH_USER, AUTH_TYPE, REMOTE_ADDR, REMOTE_USER (and more) IIS Server Variables, and I have always told you it was essentially read-only and cannot be done without altering request processing behavior. Well, now you can change them at-will, and I will provide the module that shows you how.

FYI: For the astute reader and detail-freak - this is similar to the sort of code used to test IIS7...

Now remember, with power comes responsibility. Since any module can change the state of the IIS7 request pipeline, when you have custom modules configured, one can NO LONGER trust its state nor make any expectations of IIS behavior. This will make IIS7 harder to debug because you MUST know what every custom module is doing at all times in the request pipeline. FREB cannot help in general, and ETW Tracing is pretty noisy.

In other words, when it comes to debugging IIS7, it is CRITICAL to share:

  • What Global Modules are installed, especially non-default ones not shipped by Microsoft
  • What Modules are enabled to execute in URL namespace that runs your application, especially non-default managed code modules not shipped by Microsoft
  • What Handlers are configured for the applicable URL namespace that runs your application

I ask for similar things on IIS6 - what ISAPI Filters are installed and what Application Scriptmaps are applicable for your application. Just wider in scope.

But, enough about the upcoming stuff. Here's a little flashback...

  • /Headers.asp - just echos back the request headers sent by the client
  • /Headers.asp?action=set&headername=Foo&headervalue=bar - set response header of Foo with value bar. You need a raw client like WFetch to be able to see these results since web browsers ignore custom headers

Enjoy.

//David

<%
DIM headerAction, headerName, headerValue

headerAction = UCASE( Request.QueryString( "action" ) )
headerName = Request.QueryString( "headername" )
headerValue = Request.QueryString( "headervalue" )

IF headerAction = "SET" THEN
    Response.AddHeader headerName, headerValue
    Response.Write "<H2>Sent Response Headers:</H2>" & VbCrLf & _
                   "<PRE>" & VbCrLf & _
                   headerName & ": " & headerValue & VbCrLf & _
                   "</PRE>"
ELSE
    Response.Write "<H2>Received Request Headers:</H2>" & VbCrLf & _
                   "<PRE>" & VbCrLf & _
                   Request.ServerVariables( "ALL_RAW" ) & _
                   "</PRE>"
END IF
%>