Project

General

Profile

Actions

Bug #102901

open

Automatically created redirects can point to the same URL as the source

Added by Philipp Wrann 11 months ago. Updated 11 months ago.

Status:
New
Priority:
Should have
Assignee:
Category:
Link Handling & Redirect Handling
Target version:
Start date:
2024-01-23
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
11
PHP Version:
8.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

If you update a slug, typo3 will create a redirect that removes all additional query params ("Keep GET Parameters" = off).

It may happen, that - through changing of slugs - a redirect is created, that effectively looks this way:

curl -I 'https://my.site/path/to/page?type=200&cHash=someCacheHash'

HTTP/2 307 
content-type: text/html; charset=UTF-8
x-redirect-by: TYPO3 Redirect 101
location: https://my.site/path/to/page

So when generating those links in your fluid template you will never receive the content you want to load, you will always load page type 0.

This affects all required query parameters.

My suggestion:
If the source and the generated target url are the same:

1) dont send the redirect
2) if not protected, delete the obsolete redirect

Actions #1

Updated by Philipp Wrann 11 months ago

  • Description updated (diff)

Changed the location url so its clear the urls are the same

Actions #2

Updated by Stefan Bürk 11 months ago · Edited

First, you should not use "hardcoded" links in templates. Instead use proper
viewhelper which updates the correct page link after the slug has changed -
so not hitting the redirect anyway (directly).

For v11 you could disable the redirect auto creation and create custom
datahandler hook for it.

TYPO3 v12 introduced a handfull PSR-14 events around the auto redirect
creation where you can influence what kind/type of redirect is created
or create additional redirects beside the plain one.

The decision to make auto-redirect in a plain form is there since TYPO3
v9 and therefore we should not consider this as a bug and changing the
behaviour for all in a long standing LTS version.

And as already mentioned - you can adjust this for your instance using
events with TYPO3 v12 - and also doing quite more things.

For example:

https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.3/Feature-94499-ProvideAdditionalPageTypeSourceAuto-createRedirectSourceType.html
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.3/Feature-99834-NewPSR-14ModifyAutoCreateRedirectRecordBeforePersistingEvent.html
https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.2/Feature-99746-NewPSR-14SlugRedirectChangeItemCreatedEvent.html

and other.

Actions #3

Updated by Stefan Bürk 11 months ago

  • Assignee set to Stefan Bürk
Actions #4

Updated by Philipp Wrann 11 months ago

First, you should not use "hardcoded" links in templates. Instead use proper viewhelper which updates the correct page link after the slug has changed - so not hitting the redirect anyway (directly).

Where did i write, that i did that?

In our case we did just what you suggested - we utilized the f:uri.page ViewHelper. But because the generated URL is exactly the same as the redirect source path typo3 will send a redirect - even if its for no reason.

For v11 you could disable the redirect auto creation and create custom datahandler hook for it.

That advice is no solution to the bug - yes this is a bug.

TYPO3 v12 introduced a handfull PSR-14 events around the auto redirect creation where you can influence what kind/type of redirect is created or create additional redirects beside the plain one.

Neither would this be a solution because the behaviour should be correct using defaults only.

We don't deal with an edge case here, we don't deal with using "hardcoded links", we deal with typo3 behaving wrongly when using its very "core api features" exactly as they are documented.

I think it should be possible to reproduce this:

1) Create a page (lets assume it has uid 2) with the slug /test
2) Add any kind of typolink generation including some additionalParams (either use fluid, typoscript, whatever, the same link generation will kick in in the end
3) change the slug of the new page to /test2 (a redirect /test => t3://page?uid=2 will be added but GET paramters will be removed on redirect)
4) change the slug back to /test (a redirect /test2 => t3://page?uid=2 will be added like before)

At this point any correctly generated link, that points to /test will be redirected because redirect number 1 is still there. But all GET params will be removed for the location header.

The behaviour is clearly wrong.

Actions

Also available in: Atom PDF