Fixed a Very Annoying Bug

I don’t usually post about fixing bugs but this one is big enough and very annoying that it warranted a post.

The problem was this: you create a new clig with a destination URL of www.cnn.com instead of http://www.cnn.com/ . Although lacking the http:// bit (the protocol part of the URL), the URL is still accepted by Cligs. That’s the right decision on purely usability grounds, but it caused a knock-on effect on the fowarding.

See when a visitor requests a clig with a destination lacking the http:// bit, the browsers treat it as part of the Cligs website. So instead of being forwarded to http://www.cnn.com/, the browsers would think Cligs is forwarding them to http://cli.gs/www.cnn.com. This page doesn’t exist on Cligs and so visitors saw an 404 Not Found error. Not good.

This took a while to fix because I couldn’t reproduce the bug. I kept seeing odd requests in the log files and simply assumed someone did a a bad link to Cligs. It was very uncommon (maybe 1 request like this every 2-3 weeks), so I didn’t think it was a Cligs problem. But a few days ago, somone tweeted a clig and because the stars were aligned, the sun was shining, angels were singing, and I had a great cup of tea in my hand, my brain suddenly figured it out. I ran a few tests just now and implemented a fix.

So what happens now:

• As ever, you can create a clig with a destination starting with http:// or not. Up to you.
• If you don’t provide a protocol for the destination, Cligs will automatically prepend the protocol as http:// and thus forward correctly.
• Note that the default is HTTP not the secure HTTPS. So if you want a destination that is requested using HTTPS, make sure you enter that in the destination URL yourself.

As ever, if you spot something wrong please give me a shout.

This entry was posted on Samstag, Dezember 6th, 2008 at 11:32 am and is filed under Cligs News. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.