17/04/2017Stats bug resolved

The rare bug with link statistics that was mentioned in my previous post has now been fixed. All the link statistics affected have been restored to their correct values. We've also resolved the underlying cause of this problem so that it can't recur.

Posted by Richard
14/04/2017HTML5 statistics graphs and a bug

Link statistics graphs have been ported to HTML5 (via the Google Charts library) and no longer require Adobe Flash to view. Because of this they may look a little different, but should work on devices where they weren't previously visible.

While working on this I noticed an unrelated bug (also present with the old graphs) where certain statistics could appear to have reset themselves to low values. This seems to be due to a rare concurrency issue causing the unintended creation of duplicate rows in our stats database. I'll be working to fix this problem and correct the affected stats over the next few days, which will probably involve taking link statistics offline for a bit. I'll update the news page once this problem is resolved.

Posted by Richard
16/05/2016Migration to HTTPS

We've now completed our change to serving content via HTTPS only. Hopefully most people won't notice much difference.

API users who are having problems (if your app won't handle a redirect to the HTTPS URL) should update the URL they're accessing and use the HTTPS version of our API pages.

Posted by Richard
09/05/2016Migration to HTTPS

Shortened URLs are now always returned from our site and API in HTTPS format (rather than plain HTTP as previously). This is the first step in our plan to only serve pages via HTTPS, which I posted an advance notice about back in January.

For now all our pages are still also accessible via HTTP, while we monitor the impact of this change.

Posted by Richard

The site will be down for maintenance on 8 May 2016 from 01:00 UTC, while I update and reboot various servers. My initial estimate is that this will take about 2 hours.

Update: This has been done and the site is back up. It was a bit quicker than anticipated, with the total downtime being about 45 minutes.

Posted by Richard
25/01/2016Expected downtime

Our host are upgrading their power infrastructure, which requires powering down servers on a rack by rack basis. As this will affect some of our key database servers, we expect downtime during each of the windows listed below. Apologies for any inconvenience caused.

All times are in GMT/UTC. We expect actual downtime to be less than the window given (probably a few hours each time).

  • 01/02/2016 22:00 - 02/02/2016 06:00
  • 03/02/2016 22:00 - 04/02/2016 06:00

Posted by Richard
11/01/2016Migration to HTTPS

This is an advance notification that we intend to serve pages only via secure HTTPS in future. We plan to make this switch on or around 1st May 2016.

The only change that the majority of our users will notice is that we will start returning HTTPS shortened links rather than HTTP ones after we switch. All existing shortened links will still work, we will seamlessly redirect them.

API users should ensure that their apps are prepared to receive HTTPS shortened URLs in response to a shortening request. They should also either ensure that their apps are prepared to accept a redirect to the HTTPS version of the API URLs, or modify them to only access the HTTPS versions (which are already available).

Posted by Richard
08/09/2015Statistics temporarily disabled

Link statistics are offline temporarily while we replace failed hardware in one of our stats servers. I will update this post when this work has been completed. Assuming there are no unexpected issues, I expect them to be available again later today.

Update: This has now been completed and stats should be functioning again.

Posted by Richard
07/06/2015Sites now stricter about non-standard URLs

is.gd and v.gd are now more picky about what URL formats they will accept. Certain malformed URLs, URLs containing unencoded spaces, and URLs with protocols that aren't on the IANA list of assigned schemes will no longer be accepted for shortening.

Developers using our API will need to ensure that URL parameters are properly encoded (our API documentation has always stated this and gives guidance on it) to avoid running into problems.

The reason for tightening up these rules is that lately we've seen spammers linking to malformed URLs that only certain browsers will accept. Some browsers are very flexible in this regard (for example Chrome seems to accept IP addresses that are written partly in decimal and partly in hexadecimal notation). Some non-standard formats were also difficult for us to parse, reducing the effectiveness of our usual anti-spam measures.

If you notice any cases where the shorteners are now rejecting valid URLs that should be accepted, please let me know the specific URL concerned and I'll look into it.

Posted by Richard