I have a .NET 4.0 WCF web service running on a Windows 2008 R2 server. I'm not in IT, but I know the server is behind both a firewall/router, and has some manner of URL rewriting rules in place.
From within the local network I can communicate with this web service fine. It works both when the web service url points directly to the server as well as when the url points to the router's address. I'm also able to generate a service reference using either of these ways.
From outside the local network, you can browse to the .scv in a web browser and you get the standard wcf service info page. But if I try to create a service reference using this url I get the error
There was an error downloading '[Web Service URL]/_vti_bin/ListData.svc/$metadata'. The request failed with HTTP status 400: Bad Request. Metadata contains a reference that cannot be resolved: '[Web Service URL]'. Content Type application/soap+xml; charset=utf-8 was not supported by service [Web Service URL]. The client and service bindings may be mismatched. The remote server returned an error: (415) Cannot process the message because the content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8'.. If the service is defined in the current solution, try building the solution and adding the service reference again.
Google tells me that content type 'application/soap+xml; charset=utf-8' was not the expected type 'text/xml; charset=utf-8' often means the client and server bindings don't match, but it doesn't look like that's the problem, especially if it's not a consistent problem.
If I try to use the web service I get the generic error
The server did not provide a meaningful reply; this might be caused by a contract mismatch, a premature session shutdown or an internal server error
Unfortunately, this issue only seems to happen on the production server, which limits my ability to play around with diagnostic tools.
What could cause a WCF basic http web service to be visible in a browser, but not work otherwise? Also, what would cause it to think it has mismatched bindings when reached through a different endpoint (URL rewriting?)