Apache and ScriptMaps - It's killing me!
Whenever I think I finally figured out one of the cryptic configuration settings Apache laughs at me yet again with a nice big fat "Gotcha sucka!".
I've struggled through all sorts of bullshit to get scriptmapping to work with Apache. So today I'm putting the final touches on an installation routine that installs a set of scriptmaps. I've tested this setup routine with a few different scenarios and it's worked just fine. Now though for the actual final installation in the application I need this to work and just won't cooperate and I'm starting to see double as I can't figure out why.
After a lot of tinkering I finally figured out that the order of the ScriptAliasMatch and the AddType extension mapping is vital. So if I have this set up like this:
Alias /wconnect/ "C:/Program Files/Apache2.2/htdocs/wconnect/"
<directory "C:/Program Files/Apache2.2/htdocs/wconnect/">
DirectoryIndex default.htm
Options ExecCGI
AddHandler webconnection-isapi-handler dll
AddType application/webconnection-scriptmap-wc .ap .wwd .wc .wcs .wcsx .wwsoap .blog .pho .wwr .wwt
Action application/webconnection-scriptmap-wc "/wconnect/bin/wc.dll"
</directory>
ScriptAliasMatch (?i)^/wconnect/.*.(ap|wwd|wc|wcs|wcsx|wwsoap|blog|pho|wwr|wwt)$"C:\Program Files\Apache2.2\htdocs\wconnect\bin\wc.dll"
it doesn't work. Apparently when AddType is hit and no matching file is found on disk for the request Apache gives a NOT FOUND response and never moves any further down the hierarchy for looking for files.
Now I can move the ScriptAlias before the <directory> tag and the AddType and then it DOES work in firing my request at least:
Alias /wconnect/ "C:/Program Files/Apache2.2/htdocs/wconnect/"
ScriptAliasMatch (?i)^/wconnect/.*.(ap|wwd|wc|wcs|wcsx|wwsoap|blog|pho|wwr|wwt)$"C:\Program Files\Apache2.2\htdocs\wconnect\bin\wc.dll"
<directory "C:/Program Files/Apache2.2/htdocs/wconnect/">
DirectoryIndex default.htm
Options ExecCGI
AddHandler webconnection-isapi-handler dll
AddType application/webconnection-scriptmap-wc .ap .wwd .wc .wcs .wcsx .wwsoap .blog .pho .wwr .wwt
Action application/webconnection-scriptmap-wc "/wconnect/bin/wc.dll"
</directory>
The problem with this arrangement is that in the latter scenario the ScriptAliasMatch is ALWAYS used and the real problem is that Apache blows away the physical path in the process.
When a ScriptAliasMatch is applied the physical path is mapped to the Executable (ie. c:\program files\...\bin\wconnect\wc.dll) and the original reference to the file is lost. There's a LOGICAL PATH, but no physical path that can establish the original file on disk that was actually requested.
AddType routed requests on the other correctly return the physical path for a file, but because of the way this ordering works
So...
Really what this all comes down to is consistency. What I need is to be able to ALWAYS retrieve the Physical Path.
I already have a custom Module that fixes up various Apache'isms to work more like IIS. However, I have not been able to figure out how to do Path Mapping with the Apache APIs. My code is based off Mod_ISAPI and in an ISAPI extension you can typically call ServerSupportFunction and ask for HSE_MAP_PATH to do a virtual to physical mapping. Unfortunately Apache returns the physical path to the DLL as above which for IIS based ISAPI is the wrong thing (IIS returns the original mapped path regardless of whether the request was remapped to a different handler).
In ASP.NET or ASP this sort of thing would be as easy as Server.MapPath( Request.ServerVariables["Logical_Path"]).
I suspect Apache has something similar in its core API but after digging through reams of source I'm not having any luck finding it.
Any Apache experts out there? Is there a way to do path mapping even if the requested file doesn't exist?
Looking around it also seems that there's next to no documentation on the Apache internal server APIs. Nor is there a public forum - only mailing lists. Is there some place where Apache developers that deal with lower level issues hang out? If so they're not easy to find <s>...
Any help greatly appreciated...
The Voices of Reason
# re: Apache and ScriptMaps - It's killing me!
# re: Apache and ScriptMaps - It's killing me!
But what really bugs me about this particular episode is that there's so little easily discoverable content related to these topics. Apache is supposedly the most used Web Server but if you search for specific configuration or worse development related information relatively little information comes up. There's no real consolidated community either - crap is scattered all over the place. It takes a few minutes to find a qualified forum for just about any Microsoft technology and to get an answer to what (in the above case) should be a simple question is probably answered in a matter of an hour.
# re: Apache and ScriptMaps - It's killing me!
Six months ago I found a site that did a better job of Windows updates because MS updates would not install. A beautiful site. Cannot find the damn thing now (like a dumb-a@@ I didn't bookmark it).
# re: Apache and ScriptMaps - It's killing me!
These means that a) there's no public documentation at Apache of these API calls (pitiful) and b) that there hasn't been much public discussion of these API calls. These are sure not uncommon API's either as they relate to resolving Uris and will be used frequently in any Apache custom code.
As much as I often lament Microsoft Documentation as being inadequate it's very rare that you can't find ANY information on an API call in the huge pile of APIs Microsoft has. It just doesn't happen.
I guess the code's the documentation - all 90 projects of it... oh and if it would actually compile without having to fix half the projects due to invalid pre-compiler strings <s>...
# re: Apache and ScriptMaps - It's killing me!
Apache supports calling ServerSupportFunction() with an empty path input which causes Apache to return the the path physical path of the current request either as a path or if there's a default document applied with the default document. My code basically looks at this path strips the file path if there is any and then stores this path into the Path_Translated variable which passes forward properly to the ISAPI extension. So now I can get a reliable reading of PATH_TRANSLATED as far as I can tell.
It's ugly and there may be a more direct way to do this in Apache, but this works with all combinations of URLs I threw at it.
This code works with Apache for Windows 2.2 and can be added to the bottom of the mod-isapi module code after the ecb is set up. It also works with Apache 2.0 modules although a couple of changes are required to make up for the / slashes in the physical path returned.
Hope this helps out somebody.