Bug #104692
open
No site found when the url contains a plus (+) sign
0%
Description
Hi
It seems that the site is not properly resolved when the url contains a plus (+) sign.
Given the following cases:
http://typo3.cms.ddev.site/styleguide-demo-1/ : 200 OK
http://typo3.cms.ddev.site/styleguide-demo-foo/ : 404, Reason: The requested page does not exist
http://typo3.cms.ddev.site/styleguide-demo+1/ : 404, Reason: No site configuration found
but (weirdly) http://typo3.cms.ddev.site/styleguide-demo-1+foo/ : 404, Reason: The requested page does not exist
There is something inconsistent in the SiteResolver.
The anoying issue is that the 404 Handler configured for the site is not triggered when the Site is not resolved, and users are seeing the TYPO3 404 page instead of the custom one.
TYPO3 11 and reproduced on main (13.3.0-dev)
Updated by Garvin Hicking 2 months ago
- Status changed from New to Needs Feedback
Thanks for your report. Are you aware that "+" is a special character in URLs? It serves as a "space" character in URI arguments and is thus often also prevented in URL patterns to avoid issues (see for example https://www.orchidbox.com/insights/google-recommends-avoidance-of-the-plus-sign-in-your-urls/).
So I would argue using a "+" in a URL path segment is something you should avoid.
http://typo3.cms.ddev.site/styleguide-demo-1+foo/ probably works because it uses "styleguide-demo-1" and thus matches a site...
Updated by Rémy DANIEL 2 months ago
Hi Garvin
Thanks for you feedback.
Yes, I am aware that + is an encoded space, I am not trying to use spaces in slugs.
What I faces is that some malformed url are hitting TYPO3 ("old" url from an old version of the site (other CMS) migrated to TYPO3).
Those url should trigger the 404 configured for the domain.
But instead of that, no NullSite is resolved, and the "core" 404 with the TYPO3 logo is displayed.
IMHO the SiteResolver should at least resolves to a Site if the host part of the url match the Site.
Updated by Garvin Hicking 2 months ago
I understand. I don't know too much of possible implications this could have.
Meanwhile maybe you could perform a normal .htaccess/nginx config URL redirect, so that the "normal" 404 could be triggered then, until someone with experience in this area could look into a possible fix.