Otdfbt

I'm trying to deploy a Flask app on IIS (usually doing it on an Nginx/Gunicorn stack).

My stack

I'm working with Python 3.7 installed globaly, IIS 10 on Windows 10 pro.

What I tried

• Activating CGI service on IIS


• Installing wfastcgi from https://pypi.org/project/wfastcgi/
  


• Enabling wfastcgi with wfastcgi enable (and saved the output for the config file)


• Deploying my app on wwwroot/myapp
  


• Adding a web.config file on that myapp folder that looks like this:

<configuration>
 <system.webServer>
 <handlers>
 <add name="Python FastCGI"
 path="*"
 verb="*"
 modules="FastCgiModule"
 scriptProcessor="C:Program FilesPython37python.exe|C:Program FilesPython37Libsite-packageswfastcgi.py"
 resourceType="Unspecified"
 requireAccess="Script" />
 </handlers>
 </system.webServer>

 <appSettings>
 <!-- Required settings -->
 <add key="WSGI_HANDLER" value="backend.wsgi.socketio" />
 <add key="PYTHONPATH" value="C:inetpubwwwrootmyapp" />
 </appSettings>
</configuration>

socketio is the name of my Flask app, everything is ok when I run the wsgi file "standalone".

• Creating an app in IIS linked to that folder with the right physical path
  
  

  
  

  while testing app parameters, authentication step is OK, Authorization step raise a warning but not an error.

  
  

  
  

Result

When I try to reach my app I get a 500 HTTP error with the folowing 0x80070585 IIS error code.

When I "break" my web.config file (removing tag close for example), IIS tell me that the file is not well formed, so the file is reachable.

Since the error seems to come from the scriptProcessor, I double checked that both C:Program FilesPython37python.exe and C:Program FilesPython37Libsite-packageswfastcgi.py existed.
May IIS have access troubles?

I tried to inspect IIS logs, but that's not really verbose. I only have HTTP request logs.

Where should I dig to find more logs?

Thank you for yor help, note that I'm totally new to IIS and Microsoft servers, so I may have missed something big.

As Microsoft seems to give up with this stack, the only serious solution is to switch to an actively maintained solution such as Nginx or Apache. Thanx @Lex Li for the link to the communication.