Today at work I discovered a flaw in our framework that was really pretty obvious from IE6, but hadn't been noticed at all pre-testing because nobody expected it.

Our MVC architecture (Model, View, Controller) is capable of responding to HTTP requests with Smarty-generated template output, plain text, or image data. Plain text is used only for debugging and the template output is basic HTML. Both of those are fine.

When we came to implementing database image retrieval, however, we relied on the notion that browsers send a Content-Accept header of "image/*" when bringing data into an <img> tag. We used this supposed fact to automatically serve the image data with an appropriate MIME type, and without attempting to pull an HTML template through.

Now, it would make a lot more sense for content to be served according to the controller that produced it, rather than by what the remote client says it ought to be. What can I say except "management"? The upshot is that the Content-Accept request header defines what type of response is sent back.

Alas IE6 fails when someone submits an HTML form, at which point it seems to noisily accept pretty much anything. The exact Content-Accept header received by the webserver after I submitted our application's login form from my copy of IE6 is as follows:

image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/, application/, application/msword, application/xaml+xml, application/, application/x-ms-xbap, application/x-ms-application */*

Overkill? I think so, since I can't think of any reason to specify all of these possibilities and a catch-all; meanwhile, we can no longer rely on the presence of an image/* type in a request's Content-Accept string to determine what view type is appropriate. After all, it's no use our application trying to compile valid image data from a "login successful" HTML page.


It would be better if IE6 just sent a */* Content-Accept string if it really wants to. I don't know if IE7 does or not.