How To Use 410 Gone

The web uses status codes to manage communication between clients (e.g. web browsers) and servers. One of those status codes – 410 Gone – has been greatly underused. Hopefully, this article will help you to improve that.

What happens when you delete an article from your website? Nowadays, the server would return a 404 error. While effective, a 404 Not Found is a generic catch-all error. Sure it works, but we can do better. The 410 Gone code provides additional information. here’s the W3C description of the 410 Gone status code.

The resource is no longer available at the requested URI and no redirection will be given

This tells you a couple of things. First, there was previously existing content, but it was removed. It also tells you that there isn’t a resource to replace it.

Content management systems (CMS) are used to power a majority of web sites. Typically each page or article on a website — like the one you’re reading right now — lives in a database. Each article is a record in a database table with a title, content, status, and date published among other fields. These fields are all completed, with the status set to published.

When it comes to managing content, there are two types of deletes used in software projects – true deletes and soft deletes. For a true delete, the data is removed entirely, with no way to recover it. On a Linux or UNIX system, this is like running rm on a file. In a database, it means removing a record from a database table. A soft delete is different. Instead of removing a record, it’s just marked as deleted, so that any queries for published content are unable to find the record.

What we need is something a little more than a soft delete. Let’s a call it a mixed delete. Like a soft delete, the record would be marked as deleted. Like a true delete, the content should be removed from the record, except for the minimal fields your CMS needs to have it appear in its admin interface. Also, the programming logic would need to be updated so that it can find the record in the database, by not only looking for published content. This prevents the CMS from returning a 404 to the client. It would also need to check the status field for the value of ‘deleted’. These two factors would allow your programming logic to return a 410 Gone error.

Maintaining the deleted records in the database forever isn’t necessary. In fact, you probably shouldn’t. It’s just really useful for making a better web. Using the 410 Gone is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. After a sufficient period of time, you might have an automated task that regularly removes deleted records from the database.

Possible use cases

Imagine you are logged into your website. On an article you published a year ago, you see a glowing notification indicator. You click it, and see one of the links within your article has triggered a 410 Gone error. Now as the author of the article, you have the opportunity to update your article. You have the option to remove the link, or replace the URL with another.

Here’s another scenario. You have created a popular content site. After several years, you’ve decided to reorganize you website. Part of that, is removing a couple sections of articles. Each of the deleted articles in these sections, will return a 410 Gone error for 3 months. The websites that have linked to your deleted articles now get to decide how they want to deal with your deleted content. After the 3 months, when your site removes the deleted records from your database, your site will send a 404 for those articles.

Conclusion

Adding the use of the 410 Gone to our applications is an opportunity to create a better web experience. It’ll make API of your systems more intelligent. Let’s start developing our systems to make use of the 410 Gone status.