wildcard mapping on default web site
Bisantz
This is more of a deployment/install question than a dev question.
I have an ISAPI extension that hooks up with a bunch of legacy code. I want
it to be invoked on any URI request to IIS. There are docs that indicate you
can create a wildcard mapping of file extension "*" and assign it to the
dll. I have successfully created this mapping using Internet Service Mgr for
the "Default Web Site" on w2k Pro/IIS5.0 only. It works great, *ANY* uri
request and we get it it first in the extension and then pass it on.
On XP Pro/IIS5.1 [duplicated on multiple machines], when I try to use the
same Internet Serivce Mgr, the "OK" button on the add mapping dialog is
grayed out. Is there a way to turn on the "OK" button ? I am running with
admin rights and also tried using "runas /user:administrator ..."- same
results. I have not migrated to Windows 2003/II6 yet.
So .NET Visual studio uses vcdeploy.exe with XML scripts when you create an
ISAPI extension. I modified one of those to use this: <APPMAPPING
fileext="*">. But it creates a mapping of ".*" (don't want the dot) on the
web server and it is scoped to a virtual dir (I need it for the whole site).
I need a wildcard mapping of just "*" and at the "Default Web Site" level.
I'm guessing [praying] its security related and that the feature has not
been removed. Does anybody know how to install an ISAPI extension with a
wildcard mapping of just "*" at the "default web site" on XP Pro/IIS5.1 ?
thanks in advance,
Bob
David Wang [Msft]
IIS6 expanded on the functionality by allowing the configuration of multiple
wildcard application mappings (IIS5 and IIS5.1 allowed only one per-URL).
Wildcard mapping is just a type of application mapping (one that maps to all
extensions). Thus, as an application mapping, it is configured on a per-URL
level, so it can be scoped from global, per-site, or per-vdir. All of this
is configured via metadata internal to IIS stored in the metabase.
Now, the UI abstracts the manipulation of metadata for you in such a way
that it works the way you're thinking -- however, when it comes to
deployment/install, you must understand a bit of what the UI has abstracted
in order to achieve what you want.
Basically, application mappings is configured in a property called
ScriptMaps, which can be thought of as an array of strings, each element of
the array corresponds to one application mapping. The ScriptMaps property
can be set at the global, per-site, or per-vdir level, the ScriptMaps
property is inheritable for a given URL, and exist property values also
override the parent for any given URL.
For example, suppose you have two websites, website1 and website2, and you
have three scriptmaps, ScriptmapA ScriptmapB, and ScriptMap C. If you have:
a. ScriptmapA configured as global
b. ScriptmapB configured as per-site for website1
c. ScriptmapC configure as per-vdir for website1's /vdir1 virtual directory
This is what happens for various requests:
1. On a request to website2, only ScriptmapA is triggered
2. On a request to website1, anywhere under /vdir1, only ScriptmapC is
triggered
3. On a request to website1, anywhere other than /vdir1 (including /), only
ScriptmapB is triggered
Note that the "global" ScriptmapA is not invoked for all requests, and
ScriptmapB applied to all of website1 except for under /vdir1, where
ScriptmapC overrides.
So, the UI takes care of handling this metadata behavior to give you the
illusion of "global" scriptmaps, inheritance, etc. It basically makes sure
if a. exists, when edits to b. or c. happens, it copies a. to b. or c. This
means that if you're trying to deploy/install scriptmaps, you must do the
same. I have no idea how you plan on deploying/installing Scriptmaps -- for
example, it's just a few lines of ADSI/WMI Script code, but it's quite a
chore for a C/C++ program.
VS.Net probably thinks in terms of applications in a vdir and is probably
not designed to configure the full spectrum of IIS abilities. So, it
doesn't surprise me that it only does scriptmappings at a vdir level and it
doesn't allow "*" mapping -- a VS.Net tool says nothing about what's
possible on IIS.
Now, I do have a question concerning your statement "*ANY* uri request and
we get it first in the extension and then pass it on". In particular, how
are you "pass it on" on W2K/WXP? For example, suppose you *-scriptmap
ASP.Net on W2K. While I'm sure that .htm and .jpg still are returned, I'm
also sure that .asp, .php, or .pl will not work -- so the *-scriptmap on W2K
isn't really "passing it on". I can tell you that with the same DLL that
it's not going to "pass it on" on WS03 either, but IIS6 does have proper
support such that an ISAPI *can* be modified to "pass it on".
--
//David
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Bisantz" <bis...@attbi.com> wrote in message
news:SHPIa.46602$hz1.118622@sccrnsc01...
Bisantz
Thank you for your response. I think from your explanation and
recommendations that we are talking about the same thing. I will try to
answer your question and then ask for more specifics or references to solve
my specific problem.
The legacy code (running on NT4, may be able to migrate to W2K) that I will
call from the ISAPI extension is the only applicaiton that will run on the
machine. This is a large application that has several dependencies and
components that are grouped and deployed together. The app runs "as-is" and
exists today and I want to use an extension to expose it to HTTP. The web
server will not need to run .aspx, .php, .pl or anything else. Once the
request comes in, the extension will send it to the legacy app which has a
proprietary API. So when I said "pass it on", I meant any request that shows
up at this web server will be passed to the existing legacy application. If
the application does not like the URI then it will indicate that in the API
with a proprietary error/response and the extension will handle it
appropriately with HTTP status. Being able to support any URI is a
requirement for the extension. I hope this helps in understanding the "pass
it on" reference.
It sounds like that on IIS 5.1 forward (regardless of OS), I cannot define
the wildcard script mapping through the Internet Service Mgr UI (e.g. MMC
plug-in). You do not say this directly, but implied in your response. If I
am wrong with this assumption then please explain how to do it - and how to
enable the "OK" button in the MMC.
Where can I find then, an install script that allows me to install my ISAPI
extension dll with wildcard mapping the default web server ? Since I can't
define it in the UI, what would the install script look like (using Script
code to set the SriptMap properties ) for an ISAPI extension called
"c:\temp\legacy.dll" for the wildcard mapping of "*" (no dot) on the
"Default Web Server". The "Default Web Server" is the name found in the MMC
console on a base install of IIS that has no virtual directories. If you
could help answer this question, it would help me move forward on the ISAPI
extenstion.
Again, thanks for your help.
Take care,
Bob
"David Wang [Msft]" <som...@online.microsoft.com> wrote in message
news:Oo1tYs7N...@TK2MSFTNGP11.phx.gbl...
David Wang [Msft]
I presume you know how to invoke your legacy code from the ISAPI DLL as well
as send back appropriate error codes and log the error/success properly in
the IIS log file. So, the only question remains as to how to configure it
for the entire applicable website that you want your ISAPI to be triggerable
(i.e. depending on the setup of the scriptmap, either every request to the
webserver is handled by your ISAPI, or only requests to certain
website(s)/vdirs -- this completely depends on your needs).
I'm going to give instructions on how to set a *-scriptmap on website ID=1
(usually the Default Web Site). Since you are planning to dedicate this
webserver to this application, I'm not going to worry about merging
ScriptMaps such that other web applications (like ASP, PHP, CGI, ISAPI) work
I'm also assuming you're only going to create one website on this machine,
and this website's ID is 1.
To configure a *-scriptmap changed between W2K, WXP, and WS03 from the UI.
The underlying format stayed the same, however.
Configuring ScriptMaps by custom automation (JScript)
var website = GetObject("IIS://localhost/w3svc/1/root");
var customDLL = "absolute file path to your ISAPI DLL, like
c:\temp\legacy.dll";
website.ScriptMaps = "*" + "," + customDLL + "," + "1";
website.SetInfo();
Configuring ScriptMaps by ADSUTIL.VBS
CSCRIPT %SYSTEMDRIVE%\Inetpub\AdminScripts\ADSUTIL.VBS SET
W3SVC/1/ROOT/ScriptMaps "*,absolute file path to your ISAPI DLL, like
c:\temp\legacy.dll,1"
-- Note that if you have "" in your filepath to escape them from the command
shell parser appropriately so that the script actually gets the " instead of
having the command shell parser strip them. The parameters you type on the
commandline eventually distill down to the code I gave above for custom
automation (JScript) configuration.
Configuring ScriptMaps by UI
On W2K -- the wildcard extension can be entered as just * or .* from the
Application extensions list.
On WXP -- the wildcard extension must be entered as .* from the Application
extensions list.
On WS03 -- no extension is needed. You add the wildcard application mapping
in the "Wildcard application maps" list instead of the "Application
extensions" list. This is mostly because on IIS6, you can have multiple
wildcard application mappings, and the existing "Application extensions"
list does not allow duplicate extensions...
--
//David
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Bisantz" <bis...@attbi.com> wrote in message
news:dCnJa.59990$hz1.139384@sccrnsc01...
Bisantz
the adsutil.vbs script works fine and does what we need.
Your help really counts.
Thanks,
Bob
"David Wang [Msft]" <som...@online.microsoft.com> wrote in message
news:eAHVqIRO...@TK2MSFTNGP12.phx.gbl...