Improving Interoperability — the Story of a Bug
Open The Web is an initiative from Opera to encourage Web developers to use Web standards for ensuring interoperability across Web browsers (and Web clients as large). We publish articles. We participate in conferences. We contact Web sites owners that have interoperability issues. Opera users kindly report issues through Opera Bug Report Wizard. We sometimes group similar issues in a work package.
My favorite package has been “HTML served as XHTML package” (OTW-6223). Some Web sites (including high profile Web sites) send to some Web clients HTML content with the mime type
application/xhtml+xml. The parsing rules for XHTML and HTML are different. When sending
application/xhtml+xml, site owners have to be sure that their content is, at least, well-formed XML. I have written about this issue in Wrong To Be Right. We noticed that the issue was often happening with sites using Microsoft IIS and ASP.net.
Starbucks was listed under OTW-6642 (created on 2010-12-20) in the package OTW-6223. The site was sending to Opera users HTML content with
application/xhtml+xml. We tried to contact the site owners without too much success. This is one of the issues that we, the Web community, should try to address: a universal reporting system for Web sites interoperability. The biggest challenge being to find the right channel and appropriate level of communications. A system too open might lead to bashing when too closed might be ignored.
Thanks for the heads up about this happening on Starbucks.com. We tracked it down to an issue in the ASP.NET Browser Capabilities functionality.
As it turns out, if you supply ASP.NET with a browsercaps file (database of browser capabilities), it sets the response’s Content-Type to the user agent’s preferred Content-Type.
Of course, this doesn’t make a lot of sense, since HTML isn’t going to magically change into XHTML or WML or anything else simply because it’s the preferred type.
Anyway, we’ve worked around this behavior and are testing the fix. Should be out soon.
He then solved the issue on Starbucks Web sites and then wrote a blog post to explain the ASP.Net feature which created the issue. Not only it was sending the wrong information to Opera but also to clients such as wget. My favorite quote of his blog post is (emphasis is mine):
The simplest fix, of course, is to get rid of any *.browser files you may be using in your application. I understand redirecting to a mobile version of your site for mobile browsers or the like, but basing any major functionality on guesses about the user’s browser is a great path to future pain.
Rohan provided a fix by either getting rid of any
*.browser files or at least remove the instances of