I've just finished the first version of the IIS + CGI docs but the resulting configuration causes Fossil to launch and peg the CPU at 100% until IIS times out the request and kills fossil.exe. (Which is 15 minutes, by default!)

I think this happens because Fossil isn't detecting a single file name argument as a CGI script, thus giving Fossil the implicit ?cgi? parameter.

Simple test case:

PS C:\> fossil C:\inetpub\wwwroot\cgi\repo.fslcgi
C:\bin\fossil.exe: unknown command: C:\inetpub\wwwroot\cgi\repo.fslcgi
C:\bin\fossil.exe: use "help" for more information

If you give the "cgi" parameter explicitly, it does work, although it then gripes about the missing SCRIPT_NAME variable. I assume IIS will pass that variable, so that's of no real concern.

Although I make a pretty compelling argument at the top of that new document that you almost certainly should not be using CGI on Windows, it'd be a shame to have gone through all of the effort to write that document only to have it document a configuration you can't actually use.

Has anyone gotten this working before?

I assume it's a fairly easy fix, but I'm not really set up to build Windows executables here, so I'm not the best person to fix this apparent bug in fossil cgi.

There is nothing wrong with Fossil and CGI on Windows.

Please see the following link on Microsoft Docs for installing and configuring CGI for IIS: https://docs.microsoft.com/en-us/iis/configuration/system.webserver/cgi

On Windows, everything is a little bit more complicated :-(

By the way:

Fossil server/ui works very well on Windows. This should be corrected in the Setup Tutorials matrix of the server document.

There is nothing wrong with Fossil and CGI on Windows.

Have you got it working, then?

I don't believe my problem is with the IIS CGI configuration — aside from the fact that it requires so much manual configuration out of the box — but with Fossil itself.

See my simple test case. That's how my configuration launches *.fslcgi.

Please see the following link on Microsoft Docs

That's a very different path than the one I took. I'd need to know that it solves some real problem with my method before I rewrote my tutorial using that other method.

Fossil server/ui works very well on Windows.

Are you asking for someone to write www/server/windows/none.md? My main objection to that idea is that the closest equivalent of /etc/rc.d on Windows is the user's startup items, which doesn't get run until someone logs in, which pushes you toward the windows/service.md document for any true "server", as compared to some user's workstation. For a proper server, you want Fossil to start before any user logs in, and to remain running after all users have logged out.

Still, if you want such a document to exist, we're open to contributions. Now's a fine time to get it in there.

Have you got it working, then?

Yes, but not on IIS. I use Fossil CGI with Apache for Windows and the CivetWeb embedded server. This is why I say that Fossil CGI works on Windows. I do not use IIS for myself.

I don't believe my problem is with the IIS CGI configuration

I think this is exactly the problem. According to Microsoft Docs, you need to first install the CGI environment. The CGI environment ist not installed by default. The symptoms you describe at the start of the thread, let me assume that Fossil is not running in a proper CGI environment.

Are you asking for someone to write www/server/windows/none.md?

I think that the current version of this document is useful for Windows users too. The server terminates when the user logs out, this is a fact that most users will learn quickly and switch to another method.

Yes, but not on IIS. I use Fossil CGI with Apache for Windows

That's a helpful observation. It caused me to go back and re-test, and I now believe it's some combination of a difference in the way IIS launches my *.fslcgi scripts and the way Fossil then handles it when launched that way.

First, realize that fossil.exe does start when you hit this CGI URL. That means CGI is configured and working, at least to some extent.

Second, my earlier diagnosis about fossil.exe not getting the implicit ?cgi? parameter when passed a CGI script name is incorrect. Fossil supplies that verb implicitly when the calling web server passes it the GATEWAY_INTERFACE environment variable.

There are also a small number of other required environment variables for Fossil CGI to work: SCRIPT_NAME, PATH_INFO, and REQUEST_URI.

That then sent me off on a long, fruitless chase for a method to either show or set the necessary variables on IIS. I couldn't even get something so simple as this batch file to work:

    @echo off
    echo Content-type: text/plain
    echo.
    set

Configuring IIS to launch *.bat via cmd.exe and then hitting that URL results in a "502.2 Bad Gateway" error, claiming I haven't given "a complete set of HTTP headers." But I can't find any documentation that defines "complete!" All my web searching claims that Content-type and maybe the HTTP/1.0 200 OK header suffice. I've tried it both ways.

Without a method for printing the environment variables that IIS passes to CGI processes, I can't tell which of the environment variables which Fossil considers necessary is missing, short of installing a development environment on this IIS VM and then running it under a debugger. That's way more work than I want to go to just to complete this article.

I'm throwing in the towel on this for now. Even if I can get it working, it's turning out to be a lot more work than the reverse proxy method, which is more modern and more powerful besides. I can't see any good reason to sink more time into this. If someone else comes up with a fix, I'll happily test and document it, but for now, I'm done.

Meanwhile, if you want to document your Apache + Windows + Fossil method, we'd be willing to accept the contribution.

you need to first install the CGI environment

I couldn't have gotten very far in constructing my tutorial without having that installed. I just didn't document that step in my tutorial. That documentation oversight is fixed on the server-docs branch now.

I think that the current version of this document is useful for Windows users too. The server terminates when the user logs out, this is a fact that most users will learn quickly and switch to another method.

I've documented this method and its problems here.