Some time ago I had a blog post describing how to warm up an Azure Web App during deployment slots swap. In that post I explained the sequence of actions that happens during the swap. One important point in that explanation is that if a site has any app settings or connection strings that are marked as “Slot” then during slot swap those settings are read from target (e.g. Production) slot and applied to the site in the staging slot. That causes the restart of the site’s worker process so that those changes take effect and become visible as process environment variable.
The restart of the worker process is OK for the majority of the swaps. But sometimes it would be useful to pause right after the production settings were applied on the staging slot and before the actual swap of host names happens. Recently Azure Web Apps team has released a “Swap with Preview” feature that supports that use case. That feature will give you a chance to verify that the web site in the staging slot works fine with production settings. Also this will allow you to warm up/initialize the site in any way you want. For example you can generate some load on that site so that its cache is completely pre-populated. After you are satisfied with how the site works in staging slot you can complete the swap so that the site is moved to production slot and starts taking on production traffic. The site’s worker process will not be restarted during that step, which means that the worker process in production slot is exactly what you have tested in staging slot.
Note that currently this feature is in Preview meaning that it is ready to be tried but not yet recommended for use with business-critical applications.
To demonstrate how Swap with Preview works I’ve created a site and added a “Slot” setting to it with name “SlotName” and value “Production“. Continue Reading »
ruslany on October 30th 2015 in WAWS
Update on Sep 28th, 2010: The security update for the vulnerability is available. More details can be found at PHP on IIS: get the latest security updates now.
Microsoft has recently released a Security Advisory about a security vulnerability in ASP.NET. This vulnerability exists in all versions of ASP.NET. The PHP applications running on IIS are also subject to this vulnerability if ASP.NET is enabled in IIS.
IMPORTANT: Even if PHP application is not using any of the ASP.NET features the vulnerability still exists as long as ASP.NET is enabled.
More information about the vulnerability can be found at the following links:
This blog post describes how to protect you PHP applications on IIS from attacks that exploit this vulnerability. Continue Reading »
ruslany on September 22nd 2010 in PHP
This post describes some of the tips and tricks that one may find useful when solving URL-based problems for their web server or web site. Each tip/trick has a description of a problem and then an example of how it can be solved with IIS 7 URL Rewrite Module.
- Add or Remove Trailing Slash
- Enforce Lower Case URLs
- Canonical Hostnames
- Redirect to HTTPS
- Return HTTP 503 Status Code in Response
- Prevent Image Hotlinking
- Reverse Proxy to Another Site/Server
- Preserve Protocol Prefix in Reverse Proxy
- Rewrite/Redirect Based on Query String Parameter
- Avoid Rewriting of Requests for ASP.NET Web Resources
1. Add or Remove Trailing Slash
Many web applications use “virtual URLs” – that is the URLs that do not directly map to the file and directory layout on web server’s file system. An example of such application may be an ASP.NET MVC application with URL format similar to this: http://stackoverflow.com/questions/60857/modrewrite-equivalent-for-iis-7-0 or a PHP application with URL format that looks like this: http://ruslany.net/2008/11/url-rewrite-module-release-to-web/. If you try to request these URLs with or without trailing slash you will still get the same page. That is OK for human visitors, but may be a problem for search engine crawlers as well as for web analytics services. Different URLs for the same page may cause crawlers to treat the same page as different pages, thus affecting the page ranking. They will also cause Web Analytics statistics for this page to be split up. Continue Reading »
ruslany on April 8th 2009 in URLRewrite
This post has been updated from its original version to correct the installation instructions, which have changed since the time the post was written in Feb 2009.
With the addition of .NET Framework to Server Core in Windows Server 2008 R2 the Server Core installation option became even more appealing for those who want to use a very low footprint server for hosting their applications. Availability of .NET framework provides the following great benefits:
- ASP.NET support – you can now use Server Core to host your ASP.NET applications.
- IIS Remote Management – Server Core does not provide any user interface other than command line. But if you prefer to use IIS Manager UI to administer IIS, you can now use IIS Remote Manager to connect to IIS on Server Core and perform all the management tasks from within familiar UI of IIS Manager.
- PowerShell – Windows Server 2008 R2 includes IIS PowerShell snapin, which is also available on Server Core.
This post describes how to setup and configure IIS on Server Core in Windows Server 2008 R2. Specifically the following tasks are described:
- Using oclist and ocsetup commands
- Basic Installation of IIS
- Installing ASP.NET
- Installing PowerShell and IIS snap-in
- Enabling IIS Remote Management
Continue Reading »
ruslany on February 26th 2009 in Other
ASP.NET Web Forms extensively use postback mechanism in order to maintain the state of the server-side controls on the web page. This makes it somewhat tricky to perform URL rewriting for ASP.NET pages. When a server side form control is added to the web page, ASP.NET will render the response with HTML <form> tag that contains an action attribute pointing back to the page where the form control is. This means that if URL rewriting was used for that page, the action attribute will point back to the rewritten URL, not to the URL that was requested from the browser. This will cause the browser to show rewritten URL any time a postback occurs.
Continue Reading »
ruslany on October 22nd 2008 in Other
The big benefit of IIS 7 integrated request processing pipeline is the fact that all the nice and useful ASP.NET features can be used for any type of content on your web site; not just for ASP.NET-specific content. For example, ASP.NET SQL-based membership can be used to protect static files and folders. Also, ASP.NET extensibility API’s, such as IHttpHandler and IHttpModule can be used to add custom modules and handlers that would be executed even for non-ASP.NET content.
IIS 6 did not have this level of integration. ASP.NET was plugged into IIS 6 as an ISAPI extension and by default was configured to handle ONLY requests mapped to that extension – for example any request that ended with “.aspx” would be be processed by ASP.NET extension. This obviously was a big limitation for customers who wanted to be able to use ASP.NET features for all other contend on web site. The most common way to workaround that was to use “Wildcard script mapping”. This post explains how an application that used wildcard script mapping in IIS 6 can be migrated over to IIS 7.
Continue Reading »
ruslany on September 30th 2008 in Other