When permanently removing a page from your website, are there any practical benefits to setting up a "410 GONE" HTTP response for the URL (vs. letting it 404)?
Yes, the 410 Gone HTTP status code conveys that the resource requested was once available in the past, but it has now been retired or made obsolete.
The 404 Not Found HTTP status code could imply that the website has been incorrectly updated so as to be missing a file that would normally be defined there. It could also mean that the requesting client referenced a resource that never did exist and probably never will.
The 410 Gone status can have more immediate SEO implications because it tells search engines that the missing resource was intentionally removed. That should hasten the reduction of future search references to that page more so than the 404 Not Found status.
I could imagine if you have a public API, and you finally disable your long deprecated v1 after publishing like v4 or something, you could use this statuscode to make it obvious to consumers of that API. But then again one could argue that a 301 is also valid for this type of situation. It also depends on how different it is, and whether there is an actual replacement, or is it just actually gone.
From RFC 9110:
The 410 response 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. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
Related
This question already has an answer here:
HTTP status code for temporarily unavailable pages
(1 answer)
Closed 1 year ago.
Scenario: A website has one or more articles that need to be updated. The article needs be pulled offline before the editing is undertaken, an audit is completed, the article is back online. Note: The remainder of said website is online and functioning as intended.
What HTTP status code should be served to requests for the URL that is temporarily offline?
503 Service Unavailable implies a server configuration issue, but is the closest I've been able to justify.
410 Gone is not entirely appropriate since the content will return.
307 Temporary Redirect could perhaps be used, but I'd prefer to not redirect to a single 'be right back' page.
451 Unavailable For Legal Reasons could also be used where a legal mandate requires an edit / audit, but not appropriate if content is not affected by legal actions.
In your scenario, you want the URL to be temporarily unvailable until the audit is completed -- which should not take too long -- so not to convey an error, but a temporary redirection in the 300-range.
There's another server-side HTTP status code, which fits the purpose: 302 Found denoting to the client, that the URL is correct for future requests, just temporarily not available.
The complete description from here:
This response code means that the URI of requested resource has been changed temporarily. Further changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.
503 Service Unavailable
The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.
Reference
https://stackoverflow.com/a/2786603/17755263
HTTP status code 503 is described in rfc2616 as being relevant when the server is "currently unable to handle the request due to a temporary overloading or maintenance of the server".
There are cases when an application may be down for maintenance. There are cases where an application may be over capacity.
In a server application I'm developing, I'd like to be able to differentiate between these two cases in the HTTP response such that client applications can be aware of a more precise reason for the service being unavailable.
Client applications could then display to the user either an "over capacity" or a "down for maintenance" notification to users as is relevant.
I could opt for using an undefined 5XX status code (for example 520), however I'd prefer to go with a defined standard approach if there is one.
Is there a defined standard approach for differentiating in the HTTP response between being unavailable due to capacity issues and unavailable due to maintenance?
If you don't want to define your own status code, you can use 503 and set different custom error messages, according to if it is "over capacity" or "down for maintenance".
You could also set the Retry-After response header field, for example in case you know when your maintenance is done and the server is back up.
Details for the status codes:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Details for the Retry-After header field:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Don't use an undefined status code, unless you're willing to go to the process of registering it.
Also, you have the whole payload available to add additional information.
Finally, http://greenbytes.de/tech/webdav/rfc6585.html#status-429 might be of interest.
I think 410 status code "Gone" can be correct answer, it indicate that the resource was existed before, but currently it's unavailable, and wont be available any more
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
10.4.11 410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected
to be considered permanent. Clients with link editing capabilities
SHOULD delete references to the Request-URI after user approval. If
the server does not know, or has no facility to determine, whether or
not the condition is permanent, the status code 404 (Not Found) SHOULD
be used instead. This response is cacheable unless indicated
otherwise.
The 410 response 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. Such an event is common for
limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not
necessary to mark all permanently unavailable resources as "gone" or
to keep the mark for any length of time -- that is left to the
discretion of the server owner.
I have a REST endpoint accepting a POST request to mark a code as redeemed. The code can only be redeemed between certain dates.
How should I respond if someone attempts to redeem the code early?
I suspect HTTP 403, Forbidden, is the right choice but then the w3c states that "the request SHOULD NOT be repeated" whereas in this case I would anticipate the request being repeated, just at a later date.
409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.
403 Forbidden makes more sense if they are trying to redeem a coupon that has already been redeemed, though 410 Gone seams elegant in this situation as well.
404 Not Found isn't ideal because the resource does in fact exist, however you can use it if you don't want to specify a reason with the 403 or if you want to hide the existence of the resource for security reasons.
If you are using HATEOAS, then you can also head you clients off at the pass (so to speak) by only including a redeem hypermedia control in the coupon resource (retrieved via a GET) when the coupon can be redeemed; though this won't stop overly bound clients from trying to redeem it anyway.
EDIT: Thanks to some good critiques (see below), I want to caveat this answer. It is based on Richardson & Ruby's writeup, which arguably doesn't mesh well with the httpbis writing on 403 Forbidden. (Personally, now I'm learning towards 409 as explained by Tom in a separate answer.)
403 Forbidden is the best choice. I will cite RESTful Web Services by Richardson & Ruby line by line. As you will see, 403 is a great fit:
The client's request is formed correctly, but the server doesn't want to carry it out.
Check!
This is not merely the case of insufficient credentials: that would be a 401 ("Unauthorized"). This is more like a resource that is only accessible at certain times, or from certain IP addresses.
Check!
A response of 403 implies that the client requested a resource that really exists. As with with 401 ("Unauthorized"), if the server doesn't want to give out even this information, it can lie and send a 404 ("Not Found") instead.
You wrote above: "The Code representation is available to be GETted before it goes live." So, you aren't trying to hide anything. So, stick with the 403. Check!
If the client's request is well-formed, why is this status code in the 4xx series (client-side error) instead of the 5xx series (server-side error)? Because the serve made it decision based on some aspect of the request other than its form; say, the time of day the request was made.
Check! The client's request was formed corrected, but it was inappropriate for the particular time.
We went four for four. The 403 code is a winner. No other codes match as well.
All of this said, a plain, non-specific 400 wouldn't be wrong, but would not be as specific or useful.
Another answer suggested the 409 Conflict code. Although worth considering, it isn't as good a fit. Here is why. According to Richardson & Ruby again:
Getting this [409] response response means that you tried to put the server's resources into an impossible or inconsistent state. Amazon S3 gives this response code when you try to delete a bucket that is not empty.
Claiming a promotion before it is 'active' wouldn't "put a server resource into an inconsistent state." It would break some business rules -- and result in cheating -- but it wouldn't cause a logical contradiction that I see.
So, whether you realized it at the onset of asking your question or not, 403 is a great choice. :)
Since Rest URLs should represent resources I would reply with 404 - Not Found
The resource is only available between certain dates, so on any other date it is not found.
When it says the request "SHOULD NOT be repeated", it is referring to the message that you should send to the viewer.
It has nothing to do with whether an actual request is repeated. (The user will get the same 403 message over and over again if s/he so desires.)
That said, a 404 is not appropriate for this because the resource is available - just that the code is not redeemable/forbidden to redeem. It is actually harmful because it tells the user that you probably made a mistake in your URL link or server configuration.
Of course, this assumes that on the appropriate date you return a 200 instead.
I'm implementing a 'testing mode' with my website which will forbid access to certain pages while they are undergoing construction, making them only accessible to administrators for private testing. I was planning on using the 401 status code, since the page does exist but they are not allowed to use it, and they may or may not be authenticated, yet only certain users (basically me) would still be allowed to access the page.
The thing I'm wondering is if the text after the HTTP/1.1 401 part mattered? Does it have to be Unauthorized or can it basically be whatever you want to put after it, so long as the 401 is still appropriate for the error? I wanted to send a message such as Temporarily Unavailable to indicate that the page is normally available to all visitors, but is undergoing reconstruction and is temporarily unavailable. Should I do this or not?
You may change them.
The status messages (technically called "reason phrases") are only recommendations and "MAY be changed without affecting the protocol)."
See http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1
However, you SHOULD :-) still use the codes properly and give meaningful messages. Only use a 401 if your condition is what the RFC says a 401 should be.
Yes, the reason phrase can be changed. It doesn't affect the meaning of the message.
But if you need to say "temporarily unavailable", you need to make it 5xx (server) code. 503 seems right here (see RFC 2616, Section 10.5.4).
You MAY change the text (very few http clients pay any attention to it), but it is better to use the most applicable response code. Afterall, indicating the reason for failure is how the various response codes were intended to be used.
Perhaps this fits:
404 Not Found The requested resource could not be found but may be
available again in the future.[2] Subsequent requests by the client
are permissible.
I'm creating a bulletin board system, and now I'm implementing a 'delete topic' feature for admins. If someone opens the deleted topic, the server cannot find it, so it must be 404. On the other hand, the topic has existed sometime, so I must use 410. Implementing the 410 would require a new table called deleted_topics, and so would require more space. However, 410 I think is better for search engines. What do you think? Should I use 404 or 410?
404 Not found
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
The 410 response 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. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
Thanks,
Showing a 410 requires a little more effort than a 404 because to know it's a 410 you need to maintain at least a "ghost" of the former page in your database. If this is not a problem to you, I'd consider the 410 "better" and "friendlier" because it presents more information. If you don't want to be hassled with maintaining a graveyard in your database, then 404 is acceptable too, of course.
I don't like Alohci's approach of redirecting to a different page. The end result looks like the user ended up on the "input new topic" page (or whatever) by accident. This works, but I think a preferable solution would be to create a custom 410 page (or 404 page, if you don't want to support 410) with specific information for the case at hand. I.e. your 410 shouldn't just say "gone", it should say "this post has been deleted, here's a link to similar posts or a link to create a new post". Your "404" wouldn't have quite as much information available but it could still offer a subset of such information and links.
I guess the "custom 410 page" comes close in appearance to "redirecting with 301" but an important difference is that robotic users of your site (of which there are many!) will get the more accurate status, and know to purge the old link from their crawl index – this will ultimately save them and you some unnecessary traffic.
I think the correct way to do this is by sending the 410 Gone for some time and after a few weeks/months to switch to 404 Not found. Of course, it is for you to decide if that is worth the amount of time and effort.
Neither. Since you tagged your question 'SEO' I'm assuming you want the best SEO answer. If there are any backlinks (coming from outside sites) to your deleted topic all the 'link juice' will be lost with 404 and 410 status.
Instead you should definitely create some 301 redirects which point to the root of the site, the root of the forum, or a related category. You will thus preserve the link juice and you get to decide which pages of your site will benefit most.