|1&1 script limits||Wednesday 9th October 2013|
I have recently built a simple image gallery for friends & family - in order to ensure that the pictures are only displayed to people with an active logon I use a PHP script to verify the user before using the "fpassthru()" function to stream the file.|
This all worked fine on my development server, but when I moved it to hosting (the terrible 1&1), images started to randomly fail to load. Instead of getting an image the server was returning a 500 Internal Server error.
After much playing with caching and investigations it seems to come down to some sort of limit on the number of scripts that 1and1 will allow you to run. So the only way to resolve it is to run less scripts, or delay the running of scripts.
The second approach is to reduce the number of scripts run. HTTP is great, apart from one file = one request. Google's SPDY suggestions for HTTP 2.0 overcome this by allowing multiple resources to be downloaded in one request - but it's not especially developed yet and certainly not something that would work with PHP hosted this particular host. Then there is multipart MIME, but browser support for this is flaky at best.
I have currently resorted to using the Data URI Scheme, which allows image data to be embedded in the HTML as Base64 data.
There is of course a down-side to this, and that it takes a while for the script to build the HTML with all the images embedded and a while to download to your browser. Normally your browser would receive the HTML first and then start getting the images to put in the structure - with this method it gets everything at once. Overall the loading time is going to be the same (or even faster) but will appear to be slower as there is a longer period of inactivity in the interface.
A possible solution to this would be to combine the embedded image approach with lazy loading when the page is scrolled, so only having to generate X number of images at a time. Something for another day though.
|Comodo Anti-Virus download over IPv6||Monday 7th October 2013|
I've been having problems updating or downloading Comodo Anti-Virus over IPv6. I had been trying it out for a while and was quite please with it as a free offering but realised updates didn't work in my home environment.|
The issue seemed to be down to the MTU setting for IPv6 traffic. The MTU is basically the size each chunk of data gets sent over the Internet. It is generally all handled automatically these days. The catch for me came as I'm using a 4-to-6 tunnel to provide IPv6 access (i.e. my ISP doesn't provide native IPv6, so I have to tunnel to another provider, SixXS, to get IPv6 Internet).
The SixXS tunnel by default operates an MTU of 1280, instead of the "normal" 1500. And whilst you can have this changed, you have to be careful of the tunnel overheads.
In order for computers on a network to connect to IPv6 machines, there has to be a router, which advertises itself and describes the networks it links. This means IPv6 is very easy to setup as this advertisements allow everything to be automatic - unless of course, it's not configured correctly. I'm using "radvd", a standard Linux daemon for router advertisement. You can force the MTU of the link by adding at the "interface" level:
This did the job for me and once again the Comodo web-site is working fine. I have no idea why it is only that web-site that has caused me issues but there we go, my network should be much cleaner as a result too.