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.

There’s many powerful GUIs out there which you can use to interact with SVN, and make the checking out and checking in very easy. If you primarily use a desktop GUI (like me), then chances are you use a SVN client GUI to interact with SVN on a day-to-day basis.

But what happens when you need to move code between repositories?

I first realised I needed to reorganise my repositories when my single “clients” repository was growing unwieldy. It was one large repository, with all my client work organised into folders by the project name. This method keeps things very tidy, but increments the version numbers with every commit on every project and means you have a very long root log.

A better way, I realised, is to keep the unrelated projects organised in their own repositories - but how to move the code out of my client repository into a new one?

To do this, you’ll need shell access to your SVN server (surely you do - otherwise, how do you create your repositories?)

SVN provides the svnadmin dump command to export data from your repository. In my case, to dump the contents of my entire clients repository, I did the following:

svnadmin dump clients > clients-dumpfile

which creates a text file called clients-dumpfile containing all the revision data for my clients repository. Note that this can create a very large file, as it’s not stored in the ultra-efficient space-saving SVN database any longer.

Say I want to move all my code from a folder called client-1, and put it in its own repository. First thing I need to do, is to create the destination repository:

svnadmin create client-1-repository

Now - the dumpfile contains all the code for all the projects, so how do I filter out the other projects? (this is all one line)

cat clients-dumpfile | svndumpfilter include client-1 --drop-empty-revs --renumber-revs > client-1-filtered-dumpfile

What does this do? It takes the previously created clients-dumpfile and sends it through the svndumpfilter program. I’ve told it to include the client-1 folder (and throw away everything else). I’ve told it to drop the empty revisions left behind by the thrown away data, and renumber the rest of the revisions so my new repository is nicely sequentially numbered. The results from svndumpfilter are output into a new file called client-1-filtered-dumpfile.

Finally, you simply load the data into the new repository:

svnadmin load client-1-repository < client-1-filtered-dumpfile

Hopefully, you now have a populated repository with your clients’ code.

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!