Friday 31 July 2009

Setting Cache-Control headers and expanding hard drive size in VMWare Server 2.0

This morning I went in the back garden and tried to take some butterfly photos as there were lots of Painted ladys about, and a few whites as well. After sorting the photos on my comp and backing them up, I did a bit more work on my website.

I wanted to try and fix the "The XML source file is unavailable for viewing" error message that I would get in IE when trying to view source. Using Fiddler2, I found that deleting the Cache-Control header would let me view source okay. The Cache-Control header causing the problem was
no-store, no-cache, must-revalidate, post-check=0, pre-check=0

I did some googling and tried putting
<FilesMatch "\.(php)$">
Header set Cache-Control "max-age=3600, must-revalidate"
</FilesMatch>
in my .htaccess file. Unfortunately, I now just got a 500 internal server error. After checking in /etc/apache2/mods-enabled and /etc/apache2/mods-available, I saw that mod_Headers wasn't enabled, but was available. So I did
sudo a2enmod headers
sudo /etc/init.d/apache2 restart

After enabling mod_headers, the page would load, but I was getting 2 sets of Cache-Control headers,
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Cache-Control: max-age=3600, must-revalidate


So I tried changing my .htaccess rule to:
<FilesMatch "\.(php)$">
Header unset Cache-Control
Header set Cache-Control "max-age=3600, must-revalidate"
</FilesMatch>

I also checked all the .conf files in /etc/apache2 and subfolders to see if there were any cache settings in there - there weren't.

But reloading the page, I still got 2 sets of Cache-Control headers.

I tried adding the Cache-Control Header in my Nginx site config on the web server
add_header Cache-Control "max-age=3600, must-revalidate";
But after restarting Nginx, then loading the a page from the web server, I was still getting the same two sets of Cache-Control Headers.

I checked a normal website, and that had normal Cache-Control headers, so it obviously wasn't something funny on my computer adding an extra Cache-Control header to all files. I then checked a non-php file from my own website, and that had just one Cache-Control header, the one I had set in my .htaccess file. So it seemed that PHP was setting a Cache-Control header, and it couldn't be overwritten by the Server (maybe the Server was sending its headers before PHP?)

After lunch I went on Animal Crossing for a bit. Then I tried to find out what it was in my pages that was causing the
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
header to be sent. Doing some research on this, I found it was down to PHP's session management, and the setting of session.cache_limiter in php.ini.

Now I knew this, I had to try and find what cache header would work well for my purposes. I couldn't set Cache-Control: no-cache, as this would mean that the page source would be unviewable in IE (not a problem in itself, but I was having trouble viewing my 404 page in IE6 yesterday, and think it might have to do with IE not caching the page).

Unfortunately the settings that allowed cache weren't any good either - on the an image page the user can change the size that they are viewing an image at. For users without javascript, this involves setting a cookie (which contains their preferred viewing size), then reloading the page, and the image will be sized according to the value stored in the cookie. However, if the page is cached, then when the page is reloaded, it will be reloaded from cache, and so the image is still displayed the same size.

I even tried sending a Cache-Control header of max-age=1, must-revalidate, but this only seemed to contact the server every other page refresh. Eventually I tried not sending any Cache-Control header at all, and this seemed to do the trick - the browser would contact the server for each page request, but you could also view source. I also tried Cache-Control: private, must-revalidate, post-check=0, pre-check=0, and this seemed to work okay as well.

My Ubuntu Virtual Machine was saying that it had run out of hard drive space (I had allocated it 8GB). Yesterday evening I had changed the hard drive size in VMWare Server 2 so that the hard drive size for Ubuntu was 10GB. However, today I was still getting the same message from Ubuntu that it couldn't install any updates because there wasn't enough space.

I found that when you increase the hard drive size in Ubuntu, it doesn't change the size of the partition that Ubuntu is installed on. Doing some googling, it seemed that you should run GParted from the Ubuntu Live CD to increase the partition size.

Unfortunately I couldn't find the ISO file of Ubuntu anywhere, I guess I deleted it. I did have a Kubuntu iso though, so I tried booting the Virtual Machine with that. This turned out to be quite difficult, as the VMWare start up screen that says what key to press for the boot menu only pops up for about half a second.

When I had worked out what key to press (esc) to get into the boot menu, it was still quite difficult as you only get a very short time to press they key, and also you can't keep bashing escape until you get into the boot menu as if you press escape after the boot menu has opened, it will close.

After booting into the Kubuntu iso image, I found that it didn't have any Live option, and I couldn't see any option to run gparted there either. I tried a few physical CDs, and found one with Paragon Partition Magic (or something like that). I booted the virtual machine with that, but couldn't find any way to actually increase the main partition size.

So I downloaded the gparted ISO from the gparted site, which didn't actually take very long, and booted into it. Again, I couldn't see any way to increase the size of the main partition. However, after I had read the GParted Documentation - Getting Free Space, I figured out how to do it.

The problem was that I had my main partition, then an extended partition with the swap space, then the unallocated space. What I had to do was increase the extended partition to use up all the free space. This moved the unallocated space into the extended partition. I then had extend the swap space to use up all the unallocated space. Then reduce the swap space and move it to behind the unallocated space. Then reduce the extended partiton and move it to the right of the unallocated space. Then I could finally extend the main partition into the unallocated space.

After doing all that and pressing apply, I found that the final stage (increasing the size of the main partition) didn't work. I tried resizing the final partition again, and it worked okay. I was left with about 7MB of unallocated space that the main partition couldn't expand into, so I just expanded the swap space into that.

Ubuntu seems to still work okay, and now I can install the updates.

After doing that, I tried setting the correct expires/cache headers in nginx. At first I thought the headers weren't working at all, as firefox was still checking whether each file had been modified or not, and the web server was sending back a 304 Not modified header. I wanted to get it so that firefox didn't bother sending a HTTP request to check if the file had been modified or not at all.

It turned out that actually my expires directive in Nginx was working okay, why firefox was checking whether the files were up to date was because I was refreshing the page. I guess it should have been obvious to me, but I didn't think of the difference between refreshing the page and just loading the page normally.

After that I was going to install PHP 5.3.0 on the web server (currently I have 5.3.0RC3 installed on there). However, I remembered that ImageMagick was going to be updated to try and fix a problem I was having with images' XMP being corrupted after conversion. So I thought it would be sensible to get the updated version of ImageMagick before I compiled PHP 5.3.0 (since otherwise I would have to recompile PHP again when I did update ImageMagick).

I had a look on the ImageMagick website, but looking at the changelog, it didn't seem like a fix had been committed yet (I only reported it a few days ago, so not surprising). So I think I'll wait for that before I do much more work on my website. I've got tons of photos that need sorting and processing to work on in the meantime.

After dinner I was processing some pics, then a Southern FM Party In The Park track came on winamp so I got Moccle to come and listen to how skill the Southern FM DJs were. Then they had Tommi at Party in the park!!! So we started listening to that sone, which sounded like they must have been miming. The chorus bit was based on the Oompa Loompa song.

Moccle said that Blackout crew had a new song that was an Oompa Loompa song remix, so we tried to find that, but couldn't find the proper video for it on youtube. However, I did find a load of grime remixes of various songs, e.g. Pingu Riddim:

The weather today was mostly sunny in the morning and first part of the afternoon, then overcast the rest of the day.

Food
Breakfast: Blood Orange Marmalade toast sandwich; cup o' tea.
Lunch: Smoked ham with mustard, sliced Vine Tomato, sliced peppers, and iceberg lettuce sandwich; Nectarine; slice of Sultana and cherry fruit cake; Time Out (single); cup o' tea.
Dinner: Battered fish portion; fishcake; potatoes; peas; salt; ground black pepper; tomato ketchup. Pudding was a Peach & Passion fruit creamy yoghurt. Coffee; 1 piece Sainsbury's caramel chocolate; 1 piece Sainsbury's Truffle chocolate; 1 piece Sainsbury's Turkish delight chocolate; Coffee.

No comments: