One of my clients has a site that downloads a series of results as a CSV file, which they open in Excel. Unfortunately, Internet Explorer was refusing to download the file, and was presenting an error message reading “Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found.”

To add to my confusion, this was happening on the live server (PHP4), but not on my dev server (PHP5) which both use the same code.

In the end, I happened upon a Microsoft Knowledge Base article that explained the problem. Basically, IE obeys any “no-cache” headers you send to the browser. Without caching the file, Office applications cannot open the file when served over HTTPS.

How to solve the issue? Remove the cache header(s) - but how?

The PHP manual doesn’t make it entirely clear, and I found the solution by accident. To remove a header, use the same syntax as for setting a header, but only include a space after the colon.

For example, for the “Pragma” header:

header('pragma: ');

Note: You must include the space after the “:” or the header will not be unset.

In 99% of cases, all our sites look the same in Firefox 3, apart from one notable exception. In this one case, there is a 1px gap between the left-hand margin (which is centred using “margin-left: auto”) and the header image. Being the perfectionists we are, we don’t want a 1px white gap in our nice header.

Oddly, this 1px gap would come and go as the browser window is horizontally resized. This behaviour set alarm bells ringing that it’s some kind of rounding error in the “auto” positioning vs the exact pixel dimensions of our centred container.

After a bit of searching, we found an entry in John Resig’s blog (of JQuery fame), where he has stumbled upon the issue and developed a test case for the main browsers. Turns out that fixing it is a challenge, as all the browsers round the numbers differently. Problem is, there’s no standard for how the browsers should round the pixels, so fixing it in one browser will almost certainly break it in another.

Ho hum, here’s hoping for a future standard.

At work, we were using some software which, somewhat curiously, seemed to automatically log users in without them supplying the correct credentials. After much digging, inserting debug messages and experimentation, I found that PHP had the authentication values in the superglobal $_REQUEST array. The values you can use are as follows:

1
2
3
4
5
6
7
8

// Superglobal showing the username supplied
print $_SERVER['PHP_AUTH_USER'];
 
// Superglobal showing the password
print $_SERVER['PHP_AUTH_PW'];
 
// Authentication type (Basic or digest in PHP5)
print $_SERVER['AUTH_TYPE'];

This is immensely useful for me, because it opens all sorts of possibilities for single sign-on style systems. It also means I can work with non PHP files, without having to authenticate twice or rely on PHP sessions alone.

Of course, perhaps I should have looked at the PHP manual on HTTP authentication first!