Delphi native Web Service applications not working. IIS 7 seems to be stripping the pathinfo

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 runnin开发者_运维知识库g).

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 http://localhost/scripts/TestService.dll/wsdl, IIS 7 displays the page http://localhost/scripts/TestService.dll.

If I put my mouse over the WSDL link for the ITestService, I see http://localhost/scripts/TestService.dll/wsdl/ITestService in the status bar. However, when I click this link, the address bar shows http://localhost/scripts/TestService.dll/wsdl/ITestService, but I see only the HTML from http://localhost/scripts/TestService.dll. 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 http://localhost/scripts/TestService.dll?intf=ITestService. Clicking that link takes me to another HTML page, the one associated with http://localhost/scripts/TestService.dll?intf=ITestService. However, any link that includes a pathinfo following the script name, takes me simply to http://localhost/scripts/TestService.dll.

I have tested this in Delphi 7, Delphi 2010, and Delphi XE, with the same results.

I am guessing that IIS7 is stripping off the pathinfo, since even the WSDL Importer cannot get to the SOAP definition.

Tried creating a new Web service using the CGI option, and got the same result.

Have any idea what is going on?

Added: Bob Swart reports he has had no problems under Windows 7 32-bit. Downloading the 32-bit OS and will try that (in a new VM).

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 info path part was ignored. The info path 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

1. Delete the directory whose handling mappings I has messed up.

2. 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.

3. 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.

I know that this question is a little bit old, but this answer might help someone with the same problem.

When you add the Script Map in the IIS Manager it creates the handler in the web.config like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers accessPolicy="Read, Execute, Script">
            <add name="MyISAPI" path="myisapi" verb="*" modules="IsapiModule" scriptProcessor="C:\MyISAPI\myisapi_extension.dll" resourceType="Unspecified" requireAccess="Execute" preCondition="bitness32" />
        </handlers>
    </system.webServer>
</configuration>

What you need to do is to add the attribute allowPathInfo="true" to the handler. The IIS Manager doesn't have this option and you have to edit web.config manually:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers accessPolicy="Read, Execute, Script">
            <add name="MyISAPI" path="myisapi" verb="*" modules="IsapiModule" scriptProcessor="C:\MyISAPI\myisapi_extension.dll" resourceType="Unspecified" requireAccess="Execute" preCondition="bitness32" allowPathInfo="true" />
        </handlers>
    </system.webServer>
</configuration>

This way you can choose the request path of the ISAPI extension (in this example: http://HOSTNAME/MyISAPI/myisapi), otherwise without this change you will need to call the ISAPI extension with the name of the DLL (http://HOSTNAME/MyISAPI/myisapi_extension.dll)