Today IIS team has made the Go Live release of URL Rewrite Module for IIS 7.0 available for download. This release contains significant functionality and performance improvements and it is believed to have a quality level suitable for production deployments.
http://blogs.iis.net/ruslany/archive/2008/09/11/url-rewrite-module-go-live-release.aspx
IIS team has recently released an update for IIS 7.0 FastCGI module that fixes compatibility problems with several popular PHP applications. In particular, the update changes the behavior of FastCGI module in the following ways:
- REQUEST_URI server variable set by FastCGI module now includes query string and path info. Previously, lack of the query string in this server variable caused the popular CMS application Drupal to not work with FastCGI on IIS 7.0
- REQUEST_URI server variable now contains the originally requested URL path before any URL rewriting was performed. Prior to this fix, the server variable used to contain a final rewritten URL, which caused problems when using URL rewriting to enable “pretty permalinks” for popular blog engine Wordpress.
Note that above mentioned problems do not exist in IIS 6.0 FastCGI Extension, which always has been setting the REQUEST_URI server variable correctly.
The update is available for download from the following locations:
Warning: if your PHP application was coded in a way so that it relied on the REQUEST_URI server variable to contain the requested URL without a query string or to contain the final rewritten URL, then installing this update may break your application. Before applying the update, please make sure that your application does not rely on incorrect behavior of FastCGI module.
One of the things you want to avoid when deploying an ASP.NET application into production is to accidentally (or deliberately) leave the <compilation debug=”true”/> switch on within the application’s web.config file.
Doing so causes a number of non-optimal things to happen including:
1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2) Code can execute slower (since some additional debug paths are enabled)
3) Much more memory is used within the application at runtime
4) Scripts and images downloaded from the WebResources.axd handler are not cached
This last point is particularly important, since it means that all client-javascript libraries and static images that are deployed via WebResources.axd will be continually downloaded by clients on each page view request and not cached locally within the browser. This can slow down the user experience quite a bit for things like Atlas, controls like TreeView/Menu/Validators, and any other third-party control or custom code that deploys client resources. Note that the reason why these resources are not cached when debug is set to true is so that developers don’t have to continually flush their browser cache and restart it every-time they make a change to a resource handler (our assumption is that when you have debug=true set you are in active development on your site).
When <compilation debug=”false”/> is set, the WebResource.axd handler will automatically set a long cache policy on resources retrieved via it – so that the resource is only downloaded once to the client and cached there forever (it will also be cached on any intermediate proxy servers). If you have Atlas installed for your application, it will also automatically compress the content from the WebResources.axd handler for you when <compilation debug=”false”/> is set – reducing the size of any client-script javascript library or static resource for you (and not requiring you to write any custom code or configure anything within IIS to get it).
What about binaries compiled with debug symbols?
One scenario that several people find very useful is to compile/pre-compile an application or associated class libraries with debug symbols so that more detailed stack trace and line error messages can be retrieved from it when errors occur.
The good news is that you can do this without having the have the <compilation debug=”true”/> switch enabled in production. Specifically, you can use either a web deployment project or a web application project to pre-compile the code for your site with debug symbols, and then change the <compilation debug=”true”/> switch to false right before you deploy the application on the server.
The debug symbols and metadata in the compiled assemblies will increase the memory footprint of the application, but this can sometimes be an ok trade-off for more detailed error messages.
The <deployment retail=”true”/> Switch in Maching.config
If you are a server administrator and want to ensure that no one accidentally deploys an ASP.NET application in production with the <compilation debug=”true”/> switch enabled within the application’s web.config file, one trick you can use with ASP.NET V2.0 is to take advantage of the <deployment> section within your machine.config file.
Specifically, by setting this within your machine.config file:
<configuration>
<system.web>
<deployment retail=”true”/>
</system.web>
</configuration>
You will disable the <compilation debug=”true”/> switch, disable the ability to output trace output in a page, and turn off the ability to show detailed error messages remotely. Note that these last two items are security best practices you really want to follow (otherwise hackers can learn a lot more about the internals of your application than you should show them).
Setting this switch to true is probably a best practice that any company with formal production servers should follow to ensure that an application always runs with the best possible performance and no security information leakages. There isn’t a ton of documentation on this switch – but you can learn a little more about it here.