Bug #102901
open
Automatically created redirects can point to the same URL as the source
0%
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
Updated by Philipp Wrann 10 months ago
- Description updated (diff)
Changed the location url so its clear the urls are the same
Updated by Stefan Bürk 10 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.
Updated by Philipp Wrann 10 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.