Weird XML bug on iPad when displaying this site

The call came though the batphone from Mehul Harry: he was seeing an issue displaying blog posts from this site on an iPad. It was a new one on me and I quickly checked on my iPad using Safari: no problem.

HTML5 BadgeAfter a bit of back-and-forth, we’d nailed it down. If you navigated to a blog post via the Facebook app, the iPad displayed an XML error (due to the missing schema, essentially). If you navigated to the exact same blog post using Safari, it displayed fine. The weird thing is that this site doesn’t use XML; it’s HTML5, not XHTML.

Although this was news to me on the iPad, it was something I’d run into before: when I try and validate the site with the W3C HTML5 validator, it complains of exactly the same problem: bad XML. At least with the W3C validator, I could glean a little more information: in its response the web server was sending the Content-Type as application/xhtml+xml in the response header, not text/html (which is what I was expecting and which is what I would get in the browser). Why would the web server (IIS7 as it happens) send this erroneous Content-Type?

By default, ASPX files (which this site serves up; it’s a big old .NET program) are assumed to be text/html by both IIS and ASP.NET. Since the same page gets the correct Content-Type when it’s a browser making the requests, I can only assume that ASP.NET 3.5 was miscategorizing the user-agent of the request when it’s a UIWebView (what the Facebook app is using) or the W3C validator and assuming that it required XHTML. (This is the job of the machine.config file, in essence; something that, in a shared hosting environment, I have no access to in order to change it.)

Time to be clear-cut since the default was wrong. I altered the ancestor page class’s OnLoad() method (it’s the TemplatedThemePage class if you’re interested) to explicitly state that the pages returned by GraffitiCMS were text/html:

Response.AppendHeader("Content-Type", "text/html");

I recompiled, uploaded the new assemblies, and – zing – the problem was solved both on the iPad and for the validator.

Now playing on Pandora:
IIO – Runaway on Runaway [Maxi-Single]

Loading similar posts...   Loading links to posts on similar topics...

2 Responses

#1 Mehul Harry said...
08-May-13 8:29 PM

Great post, how did you catch the issue on the iPad? Or was it just intuition about the similar bug with the validator?

julian m bucknall avatar
#2 julian m bucknall said...
08-May-13 8:45 PM

Mehul: The error shown on the iPad was an XML error (it was complaining about a character entity if I recollect) and it was the same as the first error from the validator. So I just guessed that the UIWebView was being treated exactly the same as the validator and generating the same error.

Cheers, Julian

Leave a response

Note: some MarkDown is allowed, but HTML is not. Expand to show what's available.

  •  Emphasize with italics: surround word with underscores _emphasis_
  •  Emphasize strongly: surround word with double-asterisks **strong**
  •  Link: surround text with square brackets, url with parentheses [text](url)
  •  Inline code: surround text with backticks `IEnumerable`
  •  Unordered list: start each line with an asterisk, space * an item
  •  Ordered list: start each line with a digit, period, space 1. an item
  •  Insert code block: start each line with four spaces
  •  Insert blockquote: start each line with right-angle-bracket, space > Now is the time...
Preview of response