An anatomy of bug hunting in cross-platform web development

authored by Frank Lynam at 16/09/2012 13:02:20

I haven’t posted a blog entry in a while so in order to get the ball rolling again and given that the new academic year is almost upon us, I’ve decided to put together a very short and simple note on a technical issue that I encountered in the last few days. The problem is pretty specific and might not be of benefit to most readers. It concerns the uploading of large files to an IIS6.0 server that has the PHP5.0 web service extension installed. The point of the blog is not so much the actual technical matter at hand. It’s more to detail the processes involved in bug hunting and fixing, which all come down to perseverance and the application of research (thank god for the web).

I wrote a PHP script a while back that was fairly simple. On the client-side I used a combination of jQuery and Ajax to send a POST request to the server to access the script. Here’s the script:




ini_set("display_errors", 1);


$szTourname = $_POST['tourname'];

$szSubDir1 = $_POST['subdir1'];

$szSubDir2 = $_POST['subdir2'];


$oldmask = umask(0);


$szDirTour = ("../tours/" . $szTourname);

if (!file_exists($szDirTour)) mkdir($szDirTour, 0777);


if ($szSubDir1 == "") {

            $szDirTotal = $szDirTour;


else {

            $szDirTotal = ($szDirTour . "/" . $szSubDir1);

            if (!file_exists($szDirTotal)) mkdir($szDirTotal, 0777);



if ($szSubDir2 != "") {

            $szDirTotal = ($szDirTotal . "/" . $szSubDir2);

            if (!file_exists($szDirTotal)) mkdir($szDirTotal, 0777);



foreach ($_FILES["files"]["error"] as $key => $error) {

    if ($error == UPLOAD_ERR_OK) {

                        $src = $_FILES["files"]["tmp_name"][$key];

                        $dst = ($szDirTotal . "/" . $_FILES["files"]['name'][$key]);

                        echo ($src . "   " . $dst);

        move_uploaded_file($src, $dst);

    } else {

                        echo "<h2>Upload fail" . $error . "</h2>";





echo "<h2>Successfully Uploaded Files</h2>";




Besides copying across the uploaded file (or indeed files as it will cater for more than one if needs be) to the target directory, it also does a bit of work in the area of directory setup if required. So far then, so good.

This worked fine for small files but a few days ago I happened to try a 4MB file upload and it failed. I thought initially that it might have been because the file I was uploading was of a different file type (I tried an .m4a file) than the usual .mp3 and image files that I had previously been working with. My first guess was to augment the MIME types that IIS accepts. This approach proved unsuccessful. I then tried a large .mp3 file with the same result as the .m4a. With the ‘file type’ avenue explored, I shifted my investigation over to the problem of size.

I read and followed the instructions found in this short note that seemed to describe the problem that I was having but again I came no closer to finding a solution.

Finally, I focussed in on PHP. Using Chrome’s really very good debugging facilities, I was able to see the HTTP response coming back from my PHP script. I added in some error logging and found that the PHP $_FILES array was reporting the error code UPLOAD_ERR_INI_SIZE. I found a reference to my error at, where it told me that the upload size was exceeding the value of the upload_max_filesize directive in the php.ini file.

Great, I thought. There’s my solution. I duly edited the php.ini file that I found within the c:php folder. Still no joy, though. The same behaviour was observed. What to do next?

Which php.ini file was being used by IIS? I used the very helpful phpinfo() PHP function to check this and I found that IIS was in fact using the file found under c:windows and not c:php after all. I made the change to the correct file and hey presto, I succeeded in getting my large file uploads to work.

So there you have it. Quite a simple fix in the end but getting to that point took me about 6 hours of web research and trial and error. And this type of practice is not uncommon for the developer. Some days can go along swimmingly. You can get huge chunks of tangible work completed. On other days you can spend 10 hours with little or no progress to show for it. As such, it can be difficult to forward project how long it will take to complete certain tasks, especially when you are working in areas that might be new to your knowledge base. In today’s development world of multifaceted technique, these times of working in lands less well trodden can be more the norm than the exception.