Ok, I now have gotten questions about SSI #exec behavior on IIS6 for both ISAPI (ASP) and CGI (Perl) resources, so here is the consolidation of it all...
I have searched Google to help me figure out a problem I am having, and every search result I get brings up pages on your site. Unfortunately, I haven't found a solution, although your site helped me isolate the problem.
The cgi I am having trouble with is written in Perl and uses the CGI perl module with the get() function. The cgi is used as a server side include (exec method). It is a pagehits type utility. It uses the cgi get() function to get the url of the page that the cgi was included in. Pages using the cgi served under Windows 2000 with IIS 5 worked fine for the past 4 years, but now I am trying to migrate the cgi to Windows Server 2003 and IIS 6 and it is not working properly. Something changed in IIS 6 that is preventing the server side include cgi to get the proper string using the cgi get() function. The string returned is that of the cgi rather than the page the cgi is included in. I have tried making IIS 6 run in IIS5 isolation mode and it still doesn't work.
Could you provide any insight to why this is happening (I assume stronger security) and if there is anyway I could get it to work?
The answer to your question is actually in a recent blog post of mine.
I did some searching and have note found any public specifications about the proper environment used for #exec ... but if you do find a specification that would alter our decisions for #exec, please do post a comment and let me know.
Basically, SSI #exec on IIS relies on "child URL execution" for functionality. In IIS5, this ability was hacked into the core and resulted in the behavior you observed - that child URL inherited the server variable environment of the parent. In IIS6, this ability became a first-class concept and exposed to ISAPI Extensions, and since its behavior is intrinsically tied to server implementation, its behavior is also different - child URLs now have their own scope and has no idea of parent URL.
The net-effect of the change is as you observed - your CGI probably used the "URL" server variable to obtain the parent URL and maintain its count. This worked on IIS5 because #exec gave the parent's server variable environment. This does not work on IIS6 because #exec gives the child URL its own server variable environment.
There is no way to configure nor modify this behavior since it is intrinsic to how IIS6 server core works.
One way to work with this on IIS6 is to modify your CGI to take in a querystring or other parameter from the URL, and for SHTML pages containing #exec statements to denote the exact URL whose page-counter you want to increment.