Coldfusion REST API returning 'connection failure. status code unavailable.' when called remotely

Question

Now I want to prefix this with I am unsure whether this should be here or on server fault so I'll post it here to begin with.

We are developing a REST API in Coldfusion 9 which is being hosted on IIS 7 for a client which on certain calls must call another internal webservice. When making these calls from the server that the API is hosted on there are no errors, however when we make the call from a remote machine the following message is returned:

'connection failure. status code unavailable.'

I have googled the issue where the following was suggested as a fix http://www.talkingtree.com/blog/index.cfm/2004/7/28/20040729 but it does not work for me. The following are the notes from my own testing:

• The calls which are causing the issue are a mix of get, put, post and delete.
• The only common part of each call is the talking to the same webservice.
• I am able to call the webservice directly from the places where I make the remote calls to the API from.
• While all the calls make a call to the same webservice they do not all make the same call to the webservice.

Answer 1

Ideas:

Call the web service remotely using a URL that resolves to the internal ColdFusion server (e.g. http://[servername]:8300). You will probably have to some configuration to get this working. Reason for doing so is to identify if IIS or ColdFusion is the root cause. If you can hit the internal server remotely then IIS is probably the issue.

Is the web service call over SSL? If so, is remote caller also ColdFusion? If you've answered both yes, check to see if the SSL certificate is trusted by the remote caller's JVM. If not, you need to register it as part of the JVM's keystore.

Can you ping the host server from the caller? If not, does the caller need a "hosts" entry?

If enabled on your host, review the .NET filter and how it interacts with HTTP calls. I've experienced a situation where I was unable to access a folder called "/bin" because the .NET filter intercepted the requests.

Answer 2

The issue turned out to be that each of the calls required basic authentication which the calls themselves were handling, however basic authentication had been turned on in IIS which was causing IIS to intercept any requests with an Authorization header.

This causes an issue as IIS assumes that if authentication is passed up then it is for a user on that machine/domain and would reject any other credentials (which were valid for the system). It was working when we were logged into the machine because it was coming locally it did not need to authenticate the user.