Add status 410 Gone

I've fixed tests and some comments. For other comment I've written answers, because they are not fully clear to me.

It's not clear to me why this module should support that response code. It doesn't support 404 and 403 responses either, why would 410 be different?

I explained some reasons in #26.

It doesn't support 403 because that should be sent by modules that handle access control. If you want to send 404, just check that there is nothing at the URL path in question. There isn't a way to get a 410.

> While 410 is a 4xx status code, it's not really a client error. The client could have had a bookmark. They are visiting it and we're telling them the page isn't there anymore.

A client error doesn't mean that it's a user error. The same can be said about 403 and 404 responses.

Exactly because of that reason you want a real response with content here, like 403/404, like #28 said and #25 contains a reference to one other module that allows to set this up.

I'm closing this as won't fix so people won't spend more time on this, this module is not a good fit for this use case and I don't intend to support it.

@Berdir 410 is only way to tell scraping bots that the page is gone and should be removed from indexing

That's one of redirects that module should support - redirect to nowhere

It could use change record to point

- http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.11
- https://www.rfc-editor.org/rfc/rfc9110.html#name-410-gone

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 associated with the origin 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.

A 410 response is heuristically cacheable; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [CACHING]).

MR needs some work, few threads are open

Updated IS to standard

Sorry, but not. A 410 is a client error response, not a "redirect to nowhere". As I said, I agree with #28 that such a response should look like a real page, you might also get real users on those pages and they should see your page and have a way forward, not an empty/hardcoded 410 gone that they don't understand.

It sounds to me like the concern is that the module is called "Redirect" and 410 isn't a redirect. A sensible next step would be to make a copy of the module with a different name and add the 410 feature there.

The problem with using http_status_code module is that it puts the 410 configuration in a different UI. It is helpful to have all the configured HTTP responses in the same place.

The core of the module might be similar for the path lookup, but I think it can also be simpler (just path based, doesn't need the hash stuff IMHO) and similar to automated redirects on alias changes, I'd image it is mostly pattern-driven/automated, so that responses are set up automatically as content is deleted, or maybe with a checkbox on the delete confirmation form (sometimes you delete content only to replace that page with something else). I did find https://www.drupal.org/project/archived_410 → as an example that does that for archived content. If you're ok with possibly having a lot of archived content, then that might be useful.

I don't think having that on the same page is that important, as said, I don't really see that as something that editors/admins manually create as single responses.

Our use case for 410s was as part of a migration from D7 to D9. While node URL alias patterns changed in D9, redirecting from D7 aliases to the D9 nodes was handled perfectly. But the clients also had a large list of 400+ legacy content nodes over 10 years old that they explicitly did not want to migrate, but wanted to have a 410 response for the old D7 urls.

With the archived_410 module — had we used that — we would have had to migrate the nodes anyway, and transition them to "archived" resulting in extra useless content no one wanted to see in the node tables and administrative content lists.

On the other hand if this module had supported 410, we could leverage the existing redirect database tables and schema and returned a status code ( both of which is a key part of what this module does). So the only addition here would be a special handler for the 410 response code, allowing devs (or a redirect sub-module) to load up a custom HTML response to accompany the status code. It seems there is value here and also agree that cloning the module, duplicating a large part of the module functionality, schema, and UI (to the detriment of non-technical users tasked with abstractly handling their old "broken" URLs), does seem like a lot of work for a fairly small lift to accommodate another kind of status code.

@seanB hoot_status_code needs ✨ Convert config to content entities Needs review to maintain big sets of 410

The HTTP Status Code project → is not covered by the security advisory and has very few installs. I'm in agreement that the Redirect module's user interface is the best place for this because it does not require going to a different user interface.

I suppose a workaround might be to redirect to a page such as [website domain]/410gone and have that page return a 410 status code. That's an unpleasant kluge though, because the browser would improperly show the replacement URL rather than the originally requested URL.