I have following requirement:
- the user comes to a job page in our customer's website, but the job is already taken, so the page does not exist anymore
- the user should NOT get a 404 but a 410(Gone) and then be redirected to a job-overview-page where he gets the information that this job is not available anymore and a list of available jobs
- but instead of a 302(temp. moved) or a 404(current behavior) google should get a 410(gone) status to indicate that this page is permanently unavailable
- so the old url should be removed from the index and the new not be treated as a replacement
So how i can redirect the user with a 410 status? If i try something like this:
string overviewUrl = _urlContentResolver.GetAbsoluteUrl(overviewPage.ContentLink);
HttpContext context = _httpContextResolver.GetCurrent();
context.Response.Clear();
context.Response.Redirect(overviewUrl, false);
context.Response.StatusCode = 410;
context.Response.TrySkipIisCustomErrors = true;
context.Response.End();
I get a static error page in chrome with nothing but:
The page you requested was removed
But the status-code is correct(410) and also the Location
is set correctly, just no redirect.
If i use Redirect
and set the status before:
context.Response.StatusCode = 410;
context.Response.Redirect(overviewUrl, true); // true => endReponse
the redirect happens but i get a 302 instead of the desired 410.
Is this possible at all, if yes, how?
I think you're trying to bend the rules of
http
. The documentation statesIn your situation either
404
or410
seems to be the right status code, but410
does not have any statement about redirection as a correct behavior that browsers should implement, so you have to assume a redirect is not going to work.Now, to the philosophically right way to implement your way out of this...
With your stated requirements, "taken" does not mean the resource is gone. It means it exists for the client that claimed it. So, do you
302 Redirect
a different client to something else that might be considered correct? You implemented that, and it seems like the right way to do it.That said, I don't know if you "own" the behavior across the client and server to change the requirements to this approach. Looking at it from the "not found" angle, a
404
also seems reasonable. It's not found because "someone" already has the resource.In short if your requirements are set in stone, they may be in opposition to the HTTP spec. If you still must have a
410
then you would need to change the behavior on the client-side somehow. If that's JavaScript, you'd need to expect a410
from the server that returns a helpful payload that the client interprets to do something else (e.g. like a simulated redirect).If you don't "own" the client code... well that's a different problem.
There's a short blog post by Tommy Griffth that backs up what I am saying. Take a read. It says in part,
So, is it possible? Yes, but you're going to need to "fake" it by changing both client and server code.