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.
After 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 links to posts on similar topics...
2 Responses
#1 Mehul Harry said...
08-May-13 8:29 PMGreat post, how did you catch the issue on the iPad? Or was it just intuition about the similar bug with the validator?
#2 julian m bucknall said...
08-May-13 8:45 PMMehul: 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.
_emphasis_**strong**[text](url)`IEnumerable`* an item1. an item> Now is the time...Preview of response