Trying to add support for a Shibboleth single sign-on service. We have their Service Provider component running on our box and now need to access its session information. The primary mechanism it uses to make info available is by assigning the data to a set of server variables. So I need to read those server variables from within my application.

I see there's a Request.servervariables() method that would seem to be the ticket - but it does mention that:

...special extensions running on the Web Server might add additional HTTP variables to the Web Server. You can access these by telling wc.dll to specifically pull these values for each request by using the wc.ini [Extra Server Variables] section.

That sounds like what we need except we are running the .NET handler so I assume adding a section to wc.ini will not work. Is there a mechanism in place for accessing extra server vars under .NET?

--stein

That only applies to ISAPI not the .NET Module. The .NET module exposes everything IIS provides while ISPI explicitly has to go through server variables it knows about.

However, anything the client sends as Http headers will be there regardless as these special headers are contained in a special key ALL_HTTP and which you can access via:

Response.GetExtraHeader("custom-key")

Look at the incoming request data in the status display to figure what keys you need to access.

+++ Rick ---

Thanks.

The .NET module exposes everything IIS provides

That's what I needed to know. The relevant variables are part of the Shibboleth specs, so it should be easy enough to access what we need..

--stein

Just FYI for anyone who needs to get at the server vars - you can just reference Request.cServerVars to get the list of all vars. I had trouble getting the ALL_HTTP key to work consistently. (It worked under localhost but returned an empty string on the deployed site.)

--stein

I had trouble getting the ALL_HTTP key to work consistently. (It worked under localhost but returned an empty string on the deployed site.)

That seems very unlikely since this is a standard CGI key meaning it's been there since the very first version of IIS (and what came before it)...

There are some differences of how this handled between .NET And ISAPI - ISAPI has to look at ALL_HTTP while .NET catches all the HTTP_ values that IIS/CGI automatically creates from the custom client headers that aren't already parsed into other server variables sent. However, Request.GetExtraHeader() will figure that out and do the right thing regartdless of the platform you're running this under.

+++ Rick ---

So do I have the syntax wrong? I tried both of these:

Request.GetExtraHeader('ALL_HTTP')
Request.ServerVariables('ALL_HTTP')

--stein

Request.ServerVariables("ALL_HTTP") gets you the entire list of headers that was passed as a single string separated by line breaks. However - you should not use this variable because it's not consistent across handlers. ISAPI returns it, .NET Handler does not.

If you want to have access to the client headers you should always ask for them by the client header name:

Request.GetExtraHeader("Authorization")
Request.GetExtraHeader("Content-Type")
Request.GetExtraHeader("My-Custom-Header")

That function will figure out how to get the correct server header depending on what's there.

On .NET that means, reading HTTP_HEADER_NAME. On ISAPI it means ALL_HTTP then parsing the header out of the string lines there which also use HTTP_HEADER_NAME (but separated by : instead of =)

+++ Rick ---