Project

General

Profile

Actions

Feature #93882

closed

[FEATURE]: Allow "Redirects" with Status Code 410 for deleted files and Pages

Added by Anonymous over 3 years ago. Updated about 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Target version:
-
Start date:
2021-04-08
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
medium
Sprint Focus:
On Location Sprint

Description

Here is a feature idea which would be really nice to have:

I would like to be able to create "Redirects" without a target but with a status code of 410 to signal "This file is Gone on purpose".
I think a good place to create this would be the EXT:redirect, since this is currently the only place where we can define entries with URLs, that are not associated with any data.

This would require the following steps:
  1. Add the option "410 Gone" to the Status Code Select-Field
  2. Throw a 410 error if the url is requested

One problem I see with this solution is, that error handling (like 404) is handled in the Site Configuration. But we don't necessarily have a site configuration when we respond to a defined url.
On the other hand, we need a solution where the editors can add those urls via the backend. So it can't be completely done via Site Configuration.

One other possible solution would be to have another module behind a dropdown on top of the redirects module for the 410 Redirects specifically, where you have to select a page on which to create the redirects. That way we would always have a siteconfig and could configure the 410 handling as we do with the 404 handling.

I'm interested in your opinion. As soon as we have a prefered solution I will be happy to provide a patch :)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Task #89563: Add redirect typesClosedRichard Haeser2019-10-31

Actions
Actions #1

Updated by Martin Kutschker over 3 years ago

Won't the redirects be handled before any other routing? I don't quite see how responding with a 410 in "redirect" interferes with the error handling.

Another solution is a new page type. It's a placeholder page that still lingers on.

Actions #2

Updated by Anonymous over 3 years ago

  • Subject changed from [IDEA]: Allow "Redirects" with Status Code 410 for deleted files and Pages to [FEATURE]: Allow "Redirects" with Status Code 410 for deleted files and Pages

Hmm. That's also an interesting idea with the placeholder pages. But I'm not really sure if I think this is a good solution.

This might make the pagetree very messy and would produce a lot of pages without any content, which also don't behave like pages at all. They are not shown in any menus and behave more like folders than anything else. So I think they should also not be shown in the pagetree or at least have to option to hide them by clicking a checkbox. Which means a new feature for the pagetree aswell.

I checked the middlewares, that are called and the site-resolver gets called before the redirect handler. So here is my proposal for this ticket:

  1. Add a new option "410 Gone" to the error code dropdown for redirects
  2. Extend the redirect handler to check if we currently have a siteconfig with a configured 410 handler.
  3. If this is the case and we are currently on a url which has an associated 410 Redirect, call the 410 handler from the site configuration and let it handle the error.
    If this is not the case return the error code 410 and cancel the request.
  4. Optional Add possibility to automatically add a 410 redirect for pages, when they get deleted, like we do for renamed pages already.

This also has the advantage, that we can define files as "Gone" and also use regex for a whole bunch of pages without having to add dozens of placeholder pages.

Actions #3

Updated by Chris Müller over 3 years ago

I am a little bit torn about this topic: The status code 410 is semantically correct, when the page is gone forever, where a 404 is "only" a "not found". But it has only minimum relevance for Google:
https://twitter.com/JohnMu/status/1202194342712098821

Yes, a 410 is directly removed from the index, where the 404 is hold back for one or two days (it cannot be found by accident). Also a 410 is lesser crawled again than a 404 (both can come back).

But: An editor (in best case a SEO marketeer) has to choose if a 410 is the correct way when disabling/deleting a page. For the end user which visits the web page it has no relevance if it is gone forever or for another reason (I assume that you want to have different pages for 404 and 410). The information I searched for is not there. Period.

And: Also a 410 page can come back (enabling the page or reusing a slug again - maybe unknowingly).

As John Müller from Google suggests (see Twitter link above), deliver a "great" 404 page.

I don't think the effort is worth it - only to get the page out of search engine index a little bit earlier and to provide an additional error page. Maybe an extension which adds a middleware and a module is the way to go for the people who need this for some reason.

Actions #4

Updated by Guido Schmechel over 3 years ago

Actions #5

Updated by Oliver Hader about 2 years ago

  • Sprint Focus set to On Location Sprint
Actions #6

Updated by Benni Mack about 2 years ago

  • Status changed from New to Closed

I agree here: Let's focus on 404, and have custom extensions work with 410 if they need it. I don't think we should support 410 out of the box, as it is really an edge case, rather than an "editor feature" - editors are already have a hard time understand between 301 vs. 307.

If google and others change their 410 strategy we can re-open the ticket or create a new one.

Actions #7

Updated by Anonymous about 2 years ago

Sounds good to me :)
Since I'm no longer working on TYPO3 projects professionally, this is no longer a focus of mine. But thanks for checking on this ticket and discussing it. I agree this can be done via a small extension, if needed.

Actions

Also available in: Atom PDF