FastCGI ASP.NET Server Status Report 12

This is the final status report for the FastCGI ASP.NET Server. Due to a combination of a cold and schlepping around campus in 105F weather (40.6C where applicable), I’ve been a bit delirious. But not that my head is clearing, here’s the info you’ve been waiting for.

THIS WEEK’S ACCOMPLISHMENTS

The last week was a bit sparse on accomplishments. I had a lot of preparation to do to prep for the first week of school, and most problems have been resolved, but the following changes were made:

• Application checking was reworked to verify that Web.Config also exists. As it stands, the application manager checks for both Web.Config and Bin when adding an application. Web.Config doesn’t necessarily mean something is an application, but the lack of it means that it isn’t. (I’ve been told this is a IIS rule.)
• Requests that are directories but don’t end in a slash are redirected to the one with a slash.
• Case insensitive checking is used for “Web.Config”, “Bin”, and index pages to improve compatibility.
• Log levels can be set in the command line.
• Log messages can be sent to the standard output.
• ConfigurationManager.xml has been reorganized to group commands more logically.

WHERE IT STANDS NOW

At this point, the FastCGI Mono Server works completely with Lighttpd and Abyss, and when used with Apache and mod_fcgid, behaves like the default config supplied with mod_mono.

Cherokee has some problems when multiple requests are sent at the same time, but this may be a problem on either end. (In most cases, the mistake has been on my end.)

PLANS FOR THE FUTURE…

src/Mono.WebServer: Much of my work on Mono.WebServer is to be refactored and worked into Mono.WebServer (XSP package). This may mean automatic mapping support in mod_mono as well in the future.

src/Mono.WebServer.FastCgi: Most of the Mono.WebServer.FastCgi stuff will be restructured to and made more generic (think Mono.WebServer.CgiRequestWorker and Mono.WebServer.CgiApplicationHost) which will be reusable for things like SCGI support. This means fastcgi-mono-server may appear in XSP as well.

src/Mono.FastCgi: Support still needs to be finished for the Authorizer and Filter roles, and some renaming/FxCop/Gendarme needs to be applied. In the near future, I recommend bundling it with your application if you’re using it, but in the distant future, I expect it to be API stable/GAC-able.

Unfortunately, I will be taking 19 credit hours this semester, to accelerate my transition from Chemical to Computer Systems Engineering. This means I’ll have much less time to contribute, but I will continue to work on this (and my other) project.

SPECIAL THANKS

Special thanks to Google, the Mono SoC administrators, Marek, Daniel, Dick, Miguel, and everyone who commented or contributed in some way to my project! I appreciate all the support and the opportunity not to totally waste my summer.

Sincerely,
Brian Nickel

PS. Trac seems to have my IP address confused with a spammer, so I can’t report bugs on sites that don’t provide public registration. Does anyone know how I can fix this?

FastCGI ASP.NET Server Status Report 11

This status report is for the week of August 6 – August 10. This week has continued to see a lot of fine tuning bug fixes.

THIS WEEK’S ACCOMPLISHMENTS

The Changelog grew by 116 lines this week. Key features are as outlined.

• “Blocking” property was removed from Mono.FastCgi.Socket. It was only used to disable blocking on a socket that already communicated with asynchronous calls and was causing a problem with Abyss and unmanaged sockets.
• All headers are now sent in a single batch rather than one at a time. This should reduce the amount of network traffic and prevents Nginx from occasionally losing a request.
• Added documentation for Abyss X1 and Nginx.
• Fixed .in files not to hardcode mono location.
• Provide a friendly response 500 error page if no application could be found for a request.
• Added directory root detection with code borrowed from XspWorkerRequest.
• Found bug in Mono.WebServer where MonoWorkerRequest.SendFile was double closing a handle.
• Removed check for file existence when creating applications. This way proper applications can still be created when the user mistypes the path.
• Added documentation index page with important information on using paths vs. extensions, what are ASP.NET applications, how applications are handled, and running fastcgi-mono-server on a different machine than the web server. Plus brief information on how a request is actually processed, from Firefox to ASP.Default_aspx:Render(). See http://mono-soc-2007.googlecode.com/svn/trunk/brian/FastCgi/doc/index.html
• Added svn:eol-style=native to .html and .cs files.
• Added svn:mime-type to HTML and PNG files so they will show up in a web browser.
• Fixed the status line. It was being sent in the HTTP: “HTTP/1.1 200 OK” format instead of the CGI “Status: 200 OK” format. This was causing some breakage where status 200 was always being sent from web servers and Apache wasn’t working at all.
• Better output for “/help”
• Added some docs for using paths instead of directory mapping.
• Cleaned up UnmanagedSocket with proper SocketExceptions and a wait handle for EndAccept.

and

After discussion with Daniel Nauck changed the recommended method of handling ASP.NET to sending all requests to fastcgi-mono-server. The benefits are outlined at http://mono-soc-2007.googlecode.com/svn/trunk/brian/FastCgi/doc/index.html#info1 but in short they are improved security and enhanced features with application specific configuration.

PLANS FOR THE COMING WEEK

1. Continue documenting.
2. Alpha release.
3. Clean up API.
4. Adding open source tools: mailing list, bugzilla, wiki page???

CHALLENGES I’M FACING

Mostly just a million different web server nuances.

RESOURCES USED THIS WEEK

• MSDN: WaitHandle, System.Web.UI.Page, IAsyncResult
• Netcraft: Server statistics.
• Apache API reference: Trying to understand cmd_parms.
• FastCGI.com: Performance statistics.
• CGI specification: Review.
• http://svnbook.red-bean.com: Information on properties.

Sincerely,
Brian Nickel

Apache & fastcgi-mono-server, for the most part

When trying to figure out why all my requests were turning into “200 OK” from the Lighttpd and Cherokee, I discovered I’ve been sending them incorrectly, as HTTP style lines rather than CGI header style lines. Oops. With this change implemented, mod_fcgid is no longer failing on me and I’ve got what is the start of a configuration for Apache. PLEASE NOTE THIS IS NOT THE FINAL OR RECOMMENDED CONFIGURATION, but it is worth checking out.

<IfModule fcgid_module>
 <FilesMatch ".(aspx|asmx|ashx|asax|ascx|soap|rem|axd|cs|config|Config|dll)$>
    SetHandler fcgid-script
    FCGIWrapper /usr/bin/fastcgi-mono-server .aspx
    FCGIWrapper /usr/bin/fastcgi-mono-server .asmx
    FCGIWrapper /usr/bin/fastcgi-mono-server .ashx
    FCGIWrapper /usr/bin/fastcgi-mono-server .asax
    FCGIWrapper /usr/bin/fastcgi-mono-server .ascx
    FCGIWrapper /usr/bin/fastcgi-mono-server .soap
    FCGIWrapper /usr/bin/fastcgi-mono-server .rem
    FCGIWrapper /usr/bin/fastcgi-mono-server .axd
    FCGIWrapper /usr/bin/fastcgi-mono-server .cs
    FCGIWrapper /usr/bin/fastcgi-mono-server .config
    FCGIWrapper /usr/bin/fastcgi-mono-server .Config
    FCGIWrapper /usr/bin/fastcgi-mono-server .dll
    Options +ExecCGI
 </FilesMatch>

 DirectoryIndex index.aspx
 DirectoryIndex Default.aspx
 DirectoryIndex default.aspx
</IfModule>

There are two important shortcomings:

1. Just wrapping extensions is not a recommended way of working with ASP.NET, as it lacks certain security and management features. It is better to just send the whole directory to the Mono server. (More on this, Friday.) As far as I understand it, this will require a change in mod_fcgid.
2. WebResource.axd shows up as a 404 error rather than the expected resource, this can be overcome hackishly by creating an empty WebResource.axd where the other one is expected. Does anyone who knows Apache know how to overcome this?

Sincerely,
Brian Nickel

Abyss and Nginx now documented and working

Abyss and Nginx have been both been successfully tested (but not without some minor bug fixes in fastcgi-mono-server). I’m not sure how big of news this is, as I never heard of these servers until I found them in a table on Wikipedia, but apparently Nginx is big in Russia.Docs are at the usual place, and I’ve added an extra notice about the potential security risks of using ASP.NET by extensions alone. (Thanks to Daniel Nauck for pointing it out.)

Important changes that make this possible:

• Status 200 is sent again. Abyss was sending its own status (I presume 404) if the file didn’t exist and fastcgi-mono-server wasn’t sending in information.
• Blocking is no longer set for sockets. It didn’t appear to provide any essential features, as the server uses asynchronous calls anyway, but it was causing the unmanaged socket to stop listening on Abyss.
• Response headers are now stored in a string builder and sent only once the server has finished outputting them. The fast onslaught of tiny requests was causing occasional failure in Nginx.

If you use either of these server, please test them out and let me know of any issues you might encounter.

Sincerely,
Brian Nickel

FastCGI ASP.NET Server Status Report 10

This status report is for the week of July 30 – August 3. This week has seen a lot of work fine tuning and cleaning up the server so it will be more usable and useful.

THIS WEEK’S ACCOMPLISHMENTS

This week saw an explosion of development activity. Daily commits yielded a Changelog 234 lines (or 64%) larger than the week before. Key features are as outlined.

• Support was added for serving on a new Unix socket, as opposed to a piped socket or TCP socket. This can be used in several web servers in place of TCP sockets.
• Started work on documenting how to configure servers. Lighttpd and Cherokee are completely documented, Abyss is documented except for a bug appearing in ASP.NET 2.0, and the current problems with Apache2 are documented.
• Support was added for setting all command line options via environment variables, due to limitations in some servers. (MONO_FCGI_SOCKET=tcp is the same as setting /socket=tcp)
• Directories containing a “bin” directory are automatically treated as new applications. This is not a perfect way of checking for applications, as it can yield false positives, and not all applications use DLL’s, but it is pretty good for now.
• Support was added for writing to a log file.
• UnmanagedSocket now appropriately flags a closed connection.
• Sending and receiving records was redone, partially because I didn’t fully understand how reading and writing sockets worked and the request would die if Receive didn’t yield the exact number of bytes requested.
• When targetting .NET 2.0, Mono.FastCgi uses strictly generic collections. This reduces the size of the heap and should speed things up slightly.
• Records are now sent at no more than half the maximum size to avoid problems with some web servers. This behavior is similar to that of Cherokee.
• My patch to System.Net.Sockets.Socket was accepted. This patch is important because it removes the limitation of only supporting Unix and TCP sockets. (And may save some resources by not loading Mono.Unix if it isn’t needed.)
• Tons of bug fixes.

and

FastCGI Mono Server can handle full blown applications, like mojoPortal:

This is not hosted on a virtual path, but automatically recognized because the application contains a “bin” directory.

PLANS FOR THE COMING WEEK

1. I’m going to continue my work documenting servers. Each server presents different problems and test cases I may have overlooked and extends the reach of Mono.FastCgi.
2. Work with my mentor on what to do next.

CHALLENGES I’M FACING

I’m not sure how I want to proceed with the socket issue. It turns out all the problems I was having stemmed from bad implementation on my part and problems in mod_fcgid. Now that they’re overcome, the unmanaged socket is working fine. Not adding a mono specific feature to System.Net.Sockets.Socket would allow me to keep the version dependency down, make things easier if building it against MS .NET in the future, and give me an abstraction for using Named Pipes on Windows.

Another challenge is how to proceed with Apache. Admittedly, there are two existing open source implementations, both with their flaws, but both lacking things like Bugzilla, and both with highly cryptic source code. It may be best to develop a new FastCGI module under the Mono Project umbrella, to protect the project’s interests. It could be based off code from mod_mono and design attributes from my FastCGI library.

RESOURCES USED THIS WEEK

• MojoPortal forums.
• Abyss documentation.
• Wrapper scripts for other applications.

Sincerely,
Brian Nickel

Want to test fastcgi-mono-server? Here’s the scoop.

Subtitle: What you need to know about Cherokee, Lighttpd, and Apache2.

Last Friday, I made it possible to compile and install your own copy of “fastcgi-mono-server” using standard methods. Now I have some in depth information on how to configure your server and what to look out for.

lighttpd

Lighty works fantastic. With about 5 minutes of configuration, you can get ASP.NET and all its glory running. Simply follow the instructions located here or in the “doc/linux/” directory of the source package.

cherokee

Cherokee, up to and including Cherokee 0.5.6, has a bug where it fails to send an empty Stdin record if no input data is present. I could write a hack to get around this problem, but I’m holding out for now. The Cherokee 0.6 series, on the other hand, works very well with fastcgi-mono-server. If you’re ready to move to the 0.6 series, follow the instructions located here or in the “doc/linux/” directory of the source package.

apache2

Apache’s FastCGI situation is problematic. There are currently 2 implementations of FastCGI that I’m aware of: mod_fastcgi and mod_fcgid, and neither one of them is working just right. Mod_fastcgi was designed by the authors of FastCGI to be a replacement for CGI (hence the name), and is strongly tied to the paradigm of each file being its own application. It does have some tricks which would let a single server be used, but it sends some very unusual and sometimes junk parameters back to the server. It would require some major hacks to transform its parameters back into values that the server could understand.

Mod_fcgid, on the other hand, has the advantage of being younger, hipper, and more in tune with the concept of script servers. It is almost perfect except for the fact it sends the entire contents of the response to the server rather than stripping off the status line and sending it as r->status_line. This causes Apache to reject the response and display an error message. fastcgi-mono-server doesn’t send a status line of the status is 200 (Ok), so it’ll only work for pages that don’t do anything fancy or crash.