BTW... I personally don't like to go with the recommended way of setting up Mono via Cherokee (or any other web server for that matter) for one simple reason: You hand over complete control of serving ALL files (even static files) to the fastcgi-mono-server[2] process and, as a result, the performance benefits gained by using Cherokee in the first place are all but lost by going this route. I'm guessing this is the reason for using a separate Document Root and Project Root in the wizard, but again this needs to be verified.
Referring specifically to the reasoning behind handing off all requests to the FastCGI process, the docs on the Mono web site state: Paths vs. Extensions > > Most programming languages used for web sites contain all their information > within a single file format, for example, PHP uses the .php extension and > Python uses the .py extension. ASP.NET, on the other hand, uses a > combination of file types, combined with programming paradigms like session > objects, sandboxed environments, and private directories. This makes > configuring ASP.NET unique when compared to other FastCGI handlers you may > have configured. > > You could easily configure FastCGI to simply pass the 11 standard > extensions to the FastCGI Mono Server and have all remaining files processed > by standard methods, but you will suffer the following negative > consequences: > > - *Exposed files.* Some files that would normally be hidden will be > exposed. This is typically any file that appears in an App_Datadirectory. > Additionally, you may miss some files that should be private. As > ASP.NET was origianally written for the Windows operating system, many > applications use case insensitive formatting (.CONFIG == .config == > .Config) which you may miss when specifying the extensions to block. > This can pose a *security risk* > - *Missing features.* When an ASP.NET application is recognized by the > FastCGI Mono Server, it loads configuration details that would affect how > the site is displayed. For example, an application may register > index.py as its index page and for the .py extension to be handled by > IronPython within the Mono Server. The web server can't keep up with these > kinds of changes and would just show an error page, directory listing, or > whatever the default configuration may be. > > To overcome these problems, the *recommended method* for processing files > is to send all requests directly to the FastCGI Mono Server. This way, > features and security are preserved. The negative consequence is that all > files are then processed by the Mono Server and you suffer a decrease in > performance. *There are methods for overcoming this on a server-by-server > basis. For example, directories could be excluded from ASP.NET and serve > strictly static files, but this is a topic to be discussed in server > configuration pages. * > As per that last line (emphasis mine) I do recognize why the Mono team recommends using Mono/FastCGI to manage all incoming requests as this guarantee that the files and folders that should never see the light of day outside of their intended purpose (config files, etc.) will be blocked by Mono's ASP.NET engine if/when a request for them is made. It also helps avoid situations like this in the config file: ... vserver!20!match!domain!1 = *.amp.fm vserver!20!nick = dev.amp.fm vserver!20!rule!2400!disabled = 0 vserver!20!rule!2400!match = directory vserver!20!rule!2400!match!directory = /Bin vserver!20!rule!2400!match!final = 1 vserver!20!rule!2400!no_log = 0 vserver!20!rule!2400!only_secure = 0 vserver!20!rule!2300!disabled = 0 vserver!20!rule!2300!match = directory vserver!20!rule!2300!match!directory = /bin vserver!20!rule!2300!match!final = 1 vserver!20!rule!2300!no_log = 0 vserver!20!rule!2300!only_secure = 0 vserver!20!rule!2200!disabled = 0 vserver!20!rule!2200!match = directory vserver!20!rule!2200!match!directory = /App_Browsers vserver!20!rule!2200!match!final = 1 vserver!20!rule!2200!no_log = 0 vserver!20!rule!2200!only_secure = 0 vserver!20!rule!2100!disabled = 0 vserver!20!rule!2100!match = directory vserver!20!rule!2100!match!directory = /App_GlobalResources vserver!20!rule!2100!match!final = 1 vserver!20!rule!2100!no_log = 0 vserver!20!rule!2100!only_secure = 0 vserver!20!rule!2000!disabled = 0 vserver!20!rule!2000!match = directory vserver!20!rule!2000!match!directory = /App_LocalResources vserver!20!rule!2000!match!final = 1 vserver!20!rule!2000!no_log = 0 vserver!20!rule!2000!only_secure = 0 vserver!20!rule!1900!disabled = 0 vserver!20!rule!1900!match = directory vserver!20!rule!1900!match!directory = /App_Themes vserver!20!rule!1900!match!final = 1 vserver!20!rule!1900!no_log = 0 vserver!20!rule!1900!only_secure = 0 vserver!20!rule!1800!disabled = 0 vserver!20!rule!1800!match = directory vserver!20!rule!1800!match!directory = /App_WebReferences vserver!20!rule!1800!match!final = 1 vserver!20!rule!1800!no_log = 0 vserver!20!rule!1800!only_secure = 0 vserver!20!rule!1700!disabled = 0 vserver!20!rule!1700!match = directory vserver!20!rule!1700!match!directory = /App_Config vserver!20!rule!1700!match!final = 1 vserver!20!rule!1600!disabled = 0 vserver!20!rule!1600!match = directory vserver!20!rule!1600!match!directory = /App_Data vserver!20!rule!1600!match!final = 1 vserver!20!rule!1500!disabled = 0 vserver!20!rule!1500!match = directory vserver!20!rule!1500!match!directory = /App_Code vserver!20!rule!1500!match!final = 1 vserver!20!rule!1400!match = extensions vserver!20!rule!1400!match!extensions = .config,.dll,.exe,.cs,.CONFIG,.Config,.COnfig,.etc vserver!20!rule!1400!no_log = 0 vserver!20!rule!1400!only_secure = 0 ... But as far as Cherokee is concerned there is a far simpler way to handle this: Using order of precedence and the "Final" checkbox in the admin tool you can specify which directories and/or files should be served directly by Cherokee (e.g. /css, /js, /static, etc.), mark them as final, and then set your Default handler to deal with everything else that doesn't match any of the previous rules: ... vserver!20!rule!100!disabled = 0 vserver!20!rule!100!encoder!deflate = allow vserver!20!rule!100!encoder!gzip = allow vserver!20!rule!100!expiration = epoch vserver!20!rule!100!expiration!time = 10m vserver!20!rule!100!handler = fcgi vserver!20!rule!100!handler!allow_dirlist = 0 vserver!20!rule!100!handler!allow_pathinfo = 0 vserver!20!rule!100!handler!backup = 0 vserver!20!rule!100!handler!balancer = round_robin vserver!20!rule!100!handler!balancer!source!2 = 1 vserver!20!rule!100!handler!date = 1 vserver!20!rule!100!handler!group = 0 vserver!20!rule!100!handler!hidden = 0 vserver!20!rule!100!handler!iocache = 1 vserver!20!rule!100!handler!redir_symlinks = 0 vserver!20!rule!100!handler!size = 0 vserver!20!rule!100!handler!symlinks = 1 vserver!20!rule!100!handler!theme = default vserver!20!rule!100!handler!user = 0 vserver!20!rule!100!match = default vserver!20!rule!100!match!final = 1 vserver!20!rule!100!no_log = 0 vserver!20!rule!100!only_secure = 0 ... Using the above method you gain the best of both worlds and is the method I would personally recommend moving forward with. Of course I'm completely open to others opinions on this matter if you feel this chosen method is flawed. Anyone? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: [email protected] | [email protected] Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354 | http://broadcast.oreilly.com/m-david-peterson/
_______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
