[Update] I found the following apparently related entries in the HTTPERR log:
2018-07-25 14:39:06 ::1%0 49618 ::1%0 701 HTTP/1.1 GET / 400 - Hostname -
2018-07-25 14:39:06 ::1%0 49617 ::1%0 701 HTTP/1.1 GET /favicon.ico 400 - Hostname -
[Original]
I am attempting to deploy a .NET Core 2.1 application to an IIS server for the first time (I'm the developer, not a system administrator). .NET Core support was installed by a system administrator and, since I can start the command from the command line (see below) I believe it was done so correctly.
We do not yet have a certificate for this application, so I'm attempting to deploy with plain HTTP access (all pages in the application are dummy data so far, and we whitelist access to the IIS server). I have made the necessary changes in the applications startup code to avoid HTTPS redirection, and I believe I've done so correctly (see below).
Additionally, this application is bound to port 701 (since 80 is already in use). The full binding uses http, hostname myapplication.mycompany.com, port 701, and IP Address *.
The application is deployed correctly and appears to be "startable" and "stopable" via the IIS manager. However, when I Browse to the application the browser window times out after a few seconds with an ERR_CONNECTION_TIMED_OUT message.
When I start the application directly using dotnet .\myapplication.dll it reports listening on 5000 and I am able to access it from a browser running on the same machine.
Additionally, I note that this application is assigned ID 4 in IIS, but looking in the \inetpub\logs\LogFiles folder I see only W3SVC1, W3SVC2, and W3SVC3 folders and no log folder for ID 4.
Finally, I have ensured (I think) that the AppPool for this application has execute and write permissions in the deployment folder for the application.
Can anyone suggest what step I may have missed in getting IIS to run my plain http service or, failing that, how I can debug the problem without logs?
In your app pool change the .NET Framework Version to "No Managed Code".
Answering my own question:
The outside provider that maintains our private cloud servers had correctly add the DNS record for the
myapplicationsubdomain but had neglected to add a firewall rule to allow traffic into the private cloud on port 701. Adding this rule has apparently fixed the problem.