Here are the main parts (with some headers and the body omitted) of the response to a broken request for Raymond Chen’s blog – I deliberately misspelled “default” as “defult” to trigger a 404:

HTTP/1.1 302 Found
Date: Wed, 10 Dec 2008 17:46:51 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
CommunityServer: 2.1.61025.2
Location: /error-notfound.aspx?aspxerrorpath=/oldnewthing/defult.aspx
Content-Type: text/html; charset=utf-8
Content-Length: 176

So, a request for something that is not found returns 302 Found. Nice.

What happens when the browser follows the redirection to /error-notfound.aspx?aspxerrorpath=/oldnewthing/defult.aspx? This happens:

HTTP/1.1 404 Not Found
Date: Wed, 10 Dec 2008 17:46:52 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
CommunityServer: 2.1.61025.2
Content-Type: text/html; charset=utf-8
Content-Length: 11769

So, just to get this straight: when something is not found, ASP.NET returns a 302 Found response redirecting the client elsewhere. Then, when the redirect is followed, it returns a 404 Not Found response, despite the fact that this page clearly has been found, and it was the page that redirected us here that was not found.

Weird. Just plain weird.

Update: an online acquaintance (I don’t have a URL for him) has pointed me to a page on MSDN where the rationale for this behaviour is presented:

Redirect creates a new Context, Transfer does not. Redirect requires a round-trip to the browser, Transfer does not. As a result of this round-trip, Redirect rewrites the URL to reflect the location of the error page, Transfer does not.

If this seems to be an argument in favor of Transfer, it isn’t. The rationale of the ASP.NET development team is that Redirect accurately displays the URL of the custom error page…

However, at no point is it explained why displaying such an implementation detail to clients is preferable. Given that the article starts with the words:

The quality of a site should be measured not only by how well it works, but by how gracefully it fails.

it seems strange that it then recommends a technique which causes sites to fail in a singularly graceless manner.

My suggestion would be to modify your ASP.NET application configurations so that the customError capability uses the Transfer technique instead of Redirect. If that

…breaks a tenet of the design philosophy of ASP.NET…

then so be it.

But a redirect to the absolute URL of an error page? That’s just annoying. It means that I can’t try to reload the page to see if the server has recovered from whatever issues are affecting it – or, more accurately, I can try to reload, but as I’m now at the absolute URL of the error page, I just keep reloading that.

Unsurprisingly, the HTTP 1.1 standard has already provided for this kind of situation by means of the 503 Service Unavailable status code:

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.

If the blogs.msdn.com people (who, by the way, Raymond is not responsible for) would use this status code to serve their error page for the post on Raymond’s blog, I could simply come back after a few minutes and try to reload the page, as my browser would still be at the same location.

It’s also possible that they do send this status code, but with a Location: header to cause the redirect. (The server seems to be back on its feet again now, so I can’t inspect the HTTP cycle to check.)

Either way, what they do is wrong and broken. Don’t send people somewhere else to explain a 5xx Server Error status; simply serve the explanation directly using the appropriate 5xx status code, leaving your visitors ready to try a reload when the server has recovered. Otherwise, you’ll serve a lot of 200 OK responses from your error page, most of them to people who haven’t noticed that their location bar now points there as they hit [Control | Command]-R in the hope of seeing what they originally came for.

Note: A more recent post examines this aspect of ASP.NET in greater depth, and suggests the use of a configuration option that resolves the problem.

In addition, I’ve created a demonstration for Firefox, Internet Explorer and Safari (2.0.1 on Tiger, anyway). This XML file uses an XSL stylesheet which generates a conditional comment. Using Firefox’s DOM Inspector you can see that the comment is created correctly. Using Internet Explorer, a stylesheet is linked which modifies the appearance of the page’s heading. This demonstrates that the technique I’m describing can be used client-side as well as in server-side transformations.

First, the template:

<xsl:template name="conditionalComment">
    <xsl:param name="qualifier" select="'IE'"/>
    <xsl:param name="contentRTF" select="''" />
    <xsl:comment>[if <xsl:value-of select="$qualifier"/>]<![CDATA[>]]>
        <xsl:copy-of select="$contentRTF" />
        <![CDATA[<![endif]]]></xsl:comment>
</xsl:template>

Easy, yes? Well, maybe not; let’s look at it one step at a time.

The template takes two parameters:

qualifier

The qualifier for the “if” clause of the comment. Defaults to “IE”, which targets any version of Internet Explorer that recognises conditional comments.

contentRTF

The body of the comment: the stuff that IE gets to see (depending on the qualifier). This is passed as a result tree fragment; if you’re not sure what that means, you may want to go and read the relevant section of the XSLT spec. Defaults to an empty string.

We can invoke the template using the following code:

<xsl:call-template name="conditionalComment">
    <xsl:with-param name="qualifier" select="'lte IE 6'"/>
    <xsl:with-param name="contentRTF">
        &lt;link rel="stylesheet" type="text/css" href="ie-win-fixup.css" /&gt;
    </xsl:with-param>
</xsl:call-template>

That will give us a conditional comment targeting Internet Explorer versions 6 and below (“lte IE 6″). NOTE: I haven’t messed up my character entities there; the HTML we want to output really is expressed as you see above in the XSLT code.

So how does it work?

The comment is generated using the element. Note that we want to keep tight control of our whitespace here, making the rest of the template pretty unreadable. Split into its component parts, we have:

<xsl:comment>

Starts outputting our comment to the result tree. Output so far: <!--

[if <xsl:value-of select="$qualifier"/>]

Starts adding on the bits needed to make IE parse this as a conditional comment, using the value of the qualifier parameter. In the example case, our output is now up to <!--[if lte IE 6]

<![CDATA[>]]>

This CDATA section is treated as raw characters to copy to the result tree by the XSLT processor. So our output becomes:
<!--[if lte IE 6]> which is the start of our conditional comment.

<xsl:copy-of select="$contentRTF"/>

This just copies the contents of our result tree fragment to the result tree. Our output is now:

<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" xhref="ie-win-fixup.css" mce_href="ie-win-fixup.css" />

Notice that the character entity references we passed in in contentRTF (< and >) have now been turned into the actual characters we wanted, through the magic of result tree fragments. (In fact, this technique can be abused to allow invalid XML output from an XSLT processor, which is why it isn’t likely to survive into XSLT 2.0.)

<![CDATA[>![endif]]]>

Our final line uses another CDATA section to provide the markup IE needs to recognise the end of the comment, and then the closes our comment. Note again that there is no whitespace between the CDATA section and the closing-comment element: this is where IE’s CC parser might trip up, so we make do with a little unreadability for the sake of getting the result we want which, in all its refulgent splendour, now looks like:

<!--[if lte IE 6]>
<link rel="stylesheet" type="text/css" href="ie-win-fixup.css" />
<![endif]-->

So there you have it: an XSLT template for creating Internet Explorer conditional comments. Hopefully re-targeting your CSS hacks in readiness for the new age just got a little easier.

This post is now available in a Romanian translation (by Web Geek Science).

Netscape invented ABBR, while Microsoft invented ACRONYM, and both types meant the same thing. Then the W3C incorporated both in HTML 3, but with subtly different semantics. Microsoft’s meaning of ACRONYM was replaced by something different, which made the people at Microsoft so furious that to this day they still don’t support the ABBR element type!

as I came across a manifestation of this (possibly imaginary) dislike for the abbr element in Internet Explorer quite recently.

Consider the following markup fragment:

One would expect a browser which supports HTML 4 (which IE is claimed to have done since version 4) to produce a DOM structure as follows:

• Element: p
  • Text: An example of an abbreviation might be
  • Element: abbr
    • Text: Ltd.
  • Text: , used in the UK to denote a private company with limited liability.

Whereas IE actually produces the following:

• Element: p
  • Text: An example of an abbreviation might be
  • Element: abbr
  • Text: Ltd.
  • Element: /abbr
  • Text: , used in the UK to denote a private company with limited liability.

Yes, that’s correct: the initial abbr is parsed into an element, the text within remains as a childNode of the paragraph, and an element with the name /abbr is created.

If you try to use the createElement method of the document to create such an element, you naturally get an exception. But internally, IE manages to create an element whose name begins with a slash.

I don’t have a PC at home, so I can’t check right now whether or not spurious markup like Hello produces the same result, but I’ll check at work tomorrow and report back.

Long-delayed update: The example above does indeed produce the same results.