I've run into an interesting problem that I never encountered with XP or IIS 6.
Basically, I can't get a native Delphi (WebBroker) Web service server to work with a native Web service client in Windows 7 64-bit.
Here's the most basic breakdown. If I create a new Web service application in Delphi 2010 (or any version, back to Delphi 7), and access it using IE 8, I can see the HTML that the WSDLHTMLPublish component creates, but I can never get to the SOAP. In the same way, the WSDL Importer cannot get to the SOAP either. (I have IIS 7 configured to use a 32-bit application pool, and I have created a working Script Map to the Handler Mappings. In short, the 32-bit ISAPI Web service is running).
For example, I have a simple Web service server named TestService (created using the default sample interface generated when you create a new Web service server).
I installed it in a virtual directory named scripts.
If I enter the URL to the service in the address bar, IIS 7 displays the appropriate page.
If I put my mouse over the WSDL link for the ITestService, I see pathinfo part in the status bar. However, when I click this link, the address bar shows the full URL with pathinfo, but I see only the HTML from service (URL without pathinfo). There seems no way to get to the SOAP definition. IIS 7 seems to be ignoring everything after the script name (it is ignoring the pathinfo).
Additional evidence that IIS7 is stripping off the pathinfo is that if I pause my mouse over the ITestService link, the statusbar shows the service URL with a query string (no pathinfo). Clicking that link takes me to another HTML page, the one associated with the service and query string. However, any link that includes a pathinfo following the script name, takes me simply to the base URL (no pathinfo).
I have tested this in Delphi 7, Delphi 2010, and Delphi XE, with the same results (all on Windows 7 Ultimate 64-bit.
I am guessing that IIS7 is stripping off the pathinfo, since even the WSDL Importer cannot get to the SOAP definition. I get the same results with Chrome. In other words, it does not appear to be a browser issue.
Is this an IIS7 configuration issue?
Best Answer
The problem was that I had created a specific script mapping in the Handling Mappings for the ISAPI dll. This caused IIS to redirect all requests to the specific dll, which was why any request that included an infopath part was ignored. The infopath was stripped off.
What I really needed to do is to simply enable the Execute feature permission of the ISAPI-dll module mapping handler mapping. This module mapping is available for a virtual directory once you have allowed unspecified ISAPI modules (or CGI modules, if that is the kind of Web server extension you have created).
To fix my problem, I needed to
Delete the directory whose handling mappings I has messed up.
Since I already had allowed unspecified ISAPI modules (select Edit Feature Settings from the ISAPI and CGI Restrictions applet from the IIS section of the server), I then needed to add a new virtual directory for the appropriate Web site (here is where I recreated the directory that I deleted in previous step 1.
From the Handling Mappings applet for the virtual directory, you probably have the ISAPI-dll handling mapping disabled. Select it and select the Edit Feature Permissions option on the right-hand side. Enable the Execute checkbox.
Don't edit the ISAPI-dll handling mapping and add an Executable. Even though this dialog box says that Executable is optional, once you've added one, it's over. You can never remove it (I could never remove it). On one of my VM installs I had an Executable entry on this dialog box. In order to get rid of it, I had to uninstall IIS 7 and then reinstall it. (Maybe this wasn't necessary, but I could not figure out how to remove and reinstall a module mapping without entering the Executable entry).
Additionally, if your ISAPI DLL is a 32-bit DLL, and you're working in a 64-bit operating system, you need to enable 32-bit applications for the associated application pool.
I hope my pain has helped someone.