This one had me stumped. The control panel for our CMS worked fine, just as it had been since, well since forever. The problem was that when visited with Internet Explorer users were now being presented with a brief flash of the login page followed by a 404 Not Found error.

After repeatedly pummeling my desk with my head I noticed that turning off Internet Explorer’s friendly HTTP errors allowed the control panel to be viewed as expected. So why was Internet Explorer in particular interpreting the server’s response as a 404 when it was clearly a 200? I already knew that the server wasn’t issuing a 404 response and the Live HTTP headers Firefox plugin confirmed this.

The HTTP headers displayed by ieHTTPHeaders (Thanks for the tip Lyallzord) told a different story though.

The problem was eventually traced to an incorrectly referenced pngfix behaviour pngbehaviour.htc in one of the control panel stylesheets. To be honest it was news to me that it even existed, but the path was incorrect following a restructuring of site assets hence the broken reference.

It seems that Internet Explorer on recieving a 404 response for referenced behaviour will helpfully 404 the entire document.

So that’s nice.

IE7, don’t you just love it? What they gave us with one had in terms of CSS actually sort of working they took away with some of the stupidest niggly little bugs ever. Here’s another potentially large one i’m stumbled right into recently.

If your user agent string is more than 260 characters in length then your user agent string suddenly and almost magically becomes “Mozilla/4.0 (compatible; MSIE 6.0)”

Not what you’d expect to happen. Now, I know what your thinking. Why on god’s earth would your user agent string BE that long. The answer is simple. Toolbars and Spyware.

Toolbars and Spyware

The cool thing about Windows is that toolbars, spyware and crapware in general can and do add pointless shit to your Internet Explorer user agent string via the registry. Sounds good doesn’t it. Now consider the following:

1. Most store bough Windows PCs come pre-installed with tons of stupid toolbars and crapware
2. IE 7 isn’t much more secure than IE6 was in terms of spyware
3. Home users do not know or care about viruses and spyware

With me?

Try it yourself

You can easily trigger this bug yourself by editing the registry. Fire up regedit and navigate to HKLM/Software/Microsoft/Windows/CurrentVersion/Internet Settings/5./0User Agent/Post Platform. Create a new string key and fill up full of crap (enough to pass the 260 character threshold)

Next, close all instances of IE. Fire UP IE again and type the following into the address bar:

javascript:alert(navigator.userAgent)

Hit enter and IE7 should now tell you that it’s IE6. Awesome!

I firmly believe that this is one of the reasons behind problems such as the thickbox positioning bug that many people experience with IE7.

The workaround?

This is of course just another argument against relying on the user agent string to determine browser version. It really shouldn’t be done this way, yet it’s the method built into many JavaScript libraries including jQuery with it’s unreliable $.browser.version property.

If you really need to know if a browser is IE6 or IE7 then use something more solid like object detection. Simply testing for something like the following would be a better option than extracting unreliable data from the user agent string

A possible patch below redefines the browser version as “7.0″ only if the browser has already been identified as IE6 and the the presence of the XMLHttpRequest object suggests otherwise.

if(jQuery.browser.msie && parseInt(jQuery.browser.version) == 6 && this.XMLHttpRequest) {
	jQuery.browser.version = "7.0"
}

I’m thinking though that maybe this might not be bulletproof. If IE8 presents the same or similar “Hi i’m IE6!” behaviour then the above patch could incorrectly identify IE8 as IE7. This might not be as serious as IE7 vs. IE6 but it’s still an issue.

I just wish that Microsoft would put a bit more effort into writing good software. It’s not like they don’t have the resources.

The error

imagettfbbox() [function.imagettfbbox]: Could not find/open font

The specified font file existed and was readable. I was in fact testing for this eventuality using is_readable() prior to the the imagettfbbox call. After some poking around and a bit of googling I narrowed the problem down to a bug.. or feature in PHP > 4.3.0

The solution

It’s a simple fix, but what worked for me was to pass imagettfbbox an absolute path to the font. This is with PHP 5.2.0. I’ve read of this working for lots of people using various versions of PHP from 4.3.0 onwards, but it also seems that this isn’t always the solution, so your mileage may vary. As usual, it probably depends on a magic combination of seven million random compile flags.

So to sum up. Using imagettfbbox with relative font paths in PHP >= 4.3.0 may result in an error. A solution seems to be to use absolute paths. If this isn’t the issue, it could be spaces in the filename? Your really shouldn’t put spaces in filenames, what are you a windows user?

Official bug report here: http://bugs.php.net/bug.php?id=22092

Sometimes* PHP just sucks

* all the time