This works for me if I make sure test.py is executable:

#!/usr/bin/env python

print("Content-Type: text/html\n")
print("Hello")

Also, there were some strange whitespace characters in the file that were causing problems.

Note that I am running on darwin and am not really sure how to fix this on Windows.

@minux, but "runnable" on a file is a concept that doesn't exist on Windows.

We should do whatever other popular CGI servers do. (Whatever that is.) Shebang support, perhaps?

For Windows, you should handle extension whether it will be runnable.

https://github.com/mattn/go-cgiserver/blob/master/cgiserver.go

BTW: s/alexbrainmain/alexbrainman/

There's a WINAPI called ShellExecute, equals to cmd /c script.py, but have no idea if it's applicable to use this here. Maybe will link to windows dll file.
cmd should work, as all supported windows versions have cmd and cmd's behavior seems won't change.

@bradfitz
Thanks for reopening this issue.
Please allow me to clarify this issue with more details.
currently golang's cgi only supports .com, .exe, .bat and .cmd files. If one want to use golang's cgi on windows, there's only two choices: one of compiling languages, or bat script. compiling languages have many advantages, but not so handy as script languages such as perl, one of most popular cgi backend languages. On the other hand, bat lack too many modern features, so it's difficult to implement a complete service with just bat.
So if cgi support script languages, it will be far more useful than before.

Thank you, This works for me at least.
@minux
But comparing with Python's cgi module or Apache's cgi module, this still have problems.
Imaging you have tones of python script use as cgi backend, and use apache's cgi module. One day you want to use golang's cgi, then you need to modify all existing scripts. A new batch file may do this work for you, but python scripts with bat suffix may terribly misleading your IDE or code editor, or other maintainers.

code editor will not be useful for these script files, as many functions will not work, such as highlighting, autocompletion, etc.

MS Windows has different approach than *nix systems for FileType and Application association. There can be multiple associations, and association can have multiple options (first in list being default).
And verbs are like Open, Edit, Print etc...
So probably you have to call windows ShellExecute (Ex) for default or open verb action.
Read here - https://msdn.microsoft.com/en-us/library/windows/desktop/cc144148(v=vs.85).aspx

Or, we can query windows registry just once for every extensions to find registered launcher for the script, and cache it.
But if intelligent approach to auto-execute does not seems to be working, why don't we choose explicit approach? Like, if shebang specified with windows program path, and if available, use it or print sensible error on console for developer. And, also let developer specify a database of executable and their association to file types in program, which can be plugged to cgi handler, and then it will override shebang if that is also available and valid.

Apache HTTPD perhaps looks into cgi file shebang for per/python.

I agree we should use what windows shell already knows - see assoc and ftype windows commands. We could then use ShellExecute, or do it ourselves with AssocQueryString and CreateProcess.

Alex

I guess AssocQueryString make unexpected behavior when the file is .docx or something which is not expected as CGI.

unexpected behavior when the file is .docx

What does CGI do on unix when file is .docx? Or .html or whatever?

Alex

What does CGI do on unix when file is .docx? Or .html or whatever?

Windows doesn't have executable-permission as same as UNIX's one. So we have to handle the file-suffix which can runnable with white-list. If it use AssocQueryString without white-list, the server may start Microsoft Word for the .docx.

Could we just check the PE file's Console-vs-GUI type and not execute *.exe files if they're GUI exes?

Could we just check the PE file's Console-vs-GUI type and not execute *.exe files if they're GUI exes?

Yes we could do that.

Alex

I would suggest (at least as a workaround) to create a bat script test.bat that acts as a proxy/entry for the script test.py:

@echo off
python.exe test.py

These proxy scripts can then be generated automatically for all scripts that should be made available via the CGI.

I believe this is a rather common alternative to shebang on Windows.

I believe this is a rather common alternative to shebang on Windows.

I think so. Over hack can be a trouble afterwards.