Configuring IIS7.5 to work with Content Server API requests that use the PUT method

We are able to access Content Server REST functionality using the POST method. However, when we try to rename a folder using the PUT method ISS7.5 gets in the way (verb not allowed, unauthorized method).

How should we configure IIS to work with the REST API. Are there any other issues that we should be aware of?

Or should we use another web server. Configuring Apache was pretty straightforward.

Find more posts tagged with

API

AppWorks Gateway

Comments

marcel.buob@kwe.li

I just came across the same issue today. I'm using IIS 8 and the isapi_redirect.dll to integrate with tomcat. PUT and DELETE seem to be blocked by IIS. Any suggestions so far?

Anthony_Miller

I also had the same issue when trying to add a document. In my case the ApplicationPool on the IIS server died when trying to upload the document via the method. The update also failed with a BadRequest. All other functions appeared to work correctly.

Be good to get some guidance please.

Thanks

marcel.buob@kwe.li

Today I tried a new approach with http://tomcatiis.riaforge.org/ which seems to work so far.

In IIS I created a second site which is used as the frontend to the appworks tomcat only. On this site I installed the new BonCode connector with the wildcard handler to make sure all requests to this site are forwarded to the AJP-port.
The BonCodeAJP13.settings file makes the following settings

<Settings>
<Server>localhost</Server>
<Port>8009</Port>
<EnableRemoteAdmin>True</EnableRemoteAdmin>
<EnableHeaderDataSupport>True</EnableHeaderDataSupport>
<ForceSecureSession>False</ForceSecureSession>
<AllowEmptyHeaders>False</AllowEmptyHeaders>
<FlushThreshold>50000</FlushThreshold>
<ResolveRemoteAddrFrom>HTTP_X_FORWARDED_FOR</ResolveRemoteAddrFrom>
<LogLevel>1</LogLevel>
<LogDir>D:\AppWorks\logs</LogDir>
</Settings>

AllowEmptyHeaders was initially TRUE and caused a lot of parsing exceptions on the server side.

The only other configuration change was in the web.config of the of wwwroot:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <handlers>
            <remove name="BonCode-Tomcat-WC-Handler" />
            <add name="BonCode-Tomcat-WC-Handler" path="*" verb="OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,PROPFIND,PROPPATCH,MKCOL,COPY,MOVE,LOCK,UNLOKC,ACL,REPORT,VERSION-CONTROL,CHECKIN,CHECKOUT,UNCHECKOUT,SEARCH,MKWORKSPACE,UPDATE,LABEL,MERGE,BASELINE_CONTROL,MKACTIVITY" type="BonCodeIIS.BonCodeCallHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
        </handlers>
        <modules>
            <remove name="WebDAVModule" />
        </modules>
    </system.webServer>
</configuration>

Most important was to remove the WebDAVModule.

Hope this works for you as well.

Ferdinand Prantl

As Marcel said, it is absolutely essential to not configure WebDAV for the CS CGI folder. It is one of the most often mistakes in the CS installations. WebDAV should be enabled only for the single virtual directory, usually /livelinkdav, /csdav or similar and disabled for the others.

/cs        - WebDAV off (CGI/ISAPI enabled)
/csdav     - WebDAV on
/cssupport - WebDAV off (just static files)

If you access the CS REST API vie proxies like AppWorks, make sure that the proxy works transparently and doesn't forbid some HTTP requests; Tomcat or Apache.

You shouldn't introduce additional web servers just to circumvent configuration problems. It increases the TCO of the solution and makes it more complex. If you decide to consume the CS REST API via a proxy, the reason should be to get behind a firewall, increase safety against a DoS attack or similar.