Change http status 503 to 200 when serving app_offline.htm for specific URL

Question

The app_offline.htm file that ASP.NET serves returns the http status 503. This is the correct behavior for most situations. However, in the scenario where a specific URL is requested (e.g. https://www.mywebsite.com/monitor), I'd like to change the returned http status to 200, while still returning http status 503 in all other situations. Is this possible?

The reason why I want to do this is whenever we do scheduled maintenance on our website, we use the app_offline.htm file, but we don't want our uptime monitoring service (Pingdom.com) to report downtime during our scheduled maintenance.

I assume this would have to be at the IIS level because the app_offline.htm gets served very early on in the request processing cycle.

Answer 1

Note that App_Offline is only there to take the ASP.NET part down, it has nothing to do with the IIS site. All non-ASP.NET request -like .htm- will go through the normal IIS pipeline.

That being said, a HTTP 503 is an unavailable service error. The App_Offline.htm take the site partially offline, it is normal and correct that all ASP.NET request get a 503 response when the site is offline.

Bypass this with a HttpModule or whatever code in the ASP.NET pipeline is not a valid solution.

Since you'are already creating/copying the App_Offline.htm in your IIS root during maintenance, I'll suggest to add maintenance.htm as a default document for your /monitor folder or your IIS site and create/copy a maintenance.htm file in it during maintenance : then the default page will be reach whatever the ASP.NET site is offline or not.

If your probe is calling the http://servername/monitor/ uri without any page specified, it will work.

You just have to delete it -like you delete your App_Offline- after the maintenance.

Answer 2

As far as I know, the app_offline.htm logic is handled inside the ASP.NET 2.0 module but before any application loading begins (which is of course the idea behind app_offline.htm *g*).

I suggest:

• Add a virtual directory named monitor to the root of your (disabled) Website and assign it to some IIS-readable folder.
• Do not make the virtual directory an application, so ASP.NET should keep its hands off that folder.
• Put e.g. a copy of your app_offline.htm file renamed to default.htm (or whatever is in your default filename list) into that folder.

This way IIS should serve the html file with a 200 response when accessing https://www.mywebsite.com/monitor.

Ah, and to honor Adilson's warning about search engines, just add a <meta name="robots" content="noindex"> to your file in case the website is reachable by search engines.

Answer 3

If you're using IIS 7 and the integrated pipeline you can still create a HttpModule for requests that are not part of the ASP.NET pipeline, i/e .Htm requests.

http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis7-integrated-pipeline/

ASP.NET IIS 7 lifecycle

http://learn.iis.net/page.aspx/121/iis-7-modules-overview/

Answer 4

You could handle the Global.asax Application_Error method, identify your url, identify your error, redirect to your page

Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
        Dim ctx = HttpContext.Current
        dim myerror = ctx.Error
        If HttpContext.Current.Request.Path = "mypath" Then
            HttpContext.Current.Response.Redirect("~/mydestpage.aspx")
        End If
    End Sub

This will return first 302 for your previous request, and then redirects to a page that shows 200...

Answer 5

You could use http redirect at the IIS level.

Answer 6

Hey man. Take care when doing this! A 200 response can do your error page be indexed by google and others search engines.

If you still choose to do so, I think you should create a HttpModule, and put it on the top of the module stack. This module must test if the App_offline.html file exists, if so, then you test if the request came from the Site Monitor. In this case you can response with a 200, otherwise, the response code must be 503 to avoid bad site indexing.

Important: your site application pool must be in Integrated Mode.