TYPO3.Flow

Solution to be implemented:

• default is to generate URI in lowercase and match case-insensitive
• optionally enable case sensitivity so that generation and matching observe case

I have the same problem with URL parameters being lowercased by the URIBuilder. I think the case of URL parameters should not be changed, especially the case of the values!

Example:

$this->URIBuilder->URIFor('view', array('packageKey' => 'FLOW3'))

Would return an URI like .../view?packagekey=flow3.

Christopher Hlubek wrote:

I have the same problem with URL parameters being lowercased by the URIBuilder. I think the case of URL parameters should not be changed, especially the case of the values!

That can be solved like this (by moving the strtolower a little up):

Index: Route.php
===================================================================
--- Route.php    (revision 2301)
+++ Route.php    (working copy)
@@ -377,6 +377,7 @@
                 $matchingOptionalUriPortion = '';
             }
         }
+        $matchingURI = strtolower($matchingURI);

             // Remove remaining route values of applied default values:
         foreach ($this->defaults as $key => $defaultValue) {
@@ -397,7 +398,7 @@
             }
             $matchingURI .= '?' . http_build_query($routeValues, NULL, '&');
         }
-        $this->matchingURI = strtolower($matchingURI);
+        $this->matchingURI = $matchingURI;
         return TRUE;
     }

Karsten Dambekalns wrote:

That can be solved like this (by moving the strtolower a little up):
[...]

I've changed that already, gonna commit tomorrow.
Thanks!

I think this is not sufficient. Look at a route, where the parameters are in the path like uriPattern: help/{packageKey}/{documentationName}/{language}.

In this case the character case is important, but will not be maintained (even after applying the patch). The proposed patch only fixes simple parameters in the query part of the URI.

This issue is very important in my opinion, since routing with string parameters is pretty useless without the correct character case.

r2381 fixes the lowercase issue for the query part, that's good. But the non-static route parts still get lowercased, which is not suitable for string parameters. This should be fixed, too.

Christopher Hlubek wrote:

r2381 fixes the lowercase issue for the query part, that's good.
But the non-static route parts still get lowercased, which is not suitable for string parameters.

I know, I know, that's why I didn't close the ticket ;)

We've already talked about this issue earlier (see #1253). In the longterm there should be an option to explicitly allow uppercase characters in Routes/RouteParts. We could remove the strtolower-call in F3/FLOW3/MVC/Web/Routing/Route but that would lead to ugly default URIs like:
http://www.mydomain.tld/MyPackage/Standard/index
So we decided to go lowercase for now as it's quite common (and IIRC RealURL does this aswell)
Anyways, I don't think this is mission critical (at least not for the alpha version) because IMO the developer should allow "caseless" parameters anyways. That is:
If you have a controller that expects a search parameter you should return the same result independently from the case (because the administrator might want to force lower case URIs). If you really need the exact case you could use POST.
For "lookups" like page titles, the respective route part handler should be able to transform the case - like it's done in RealURL.

What do you think?

Thanks for the feedback!

Bastian Waidelich wrote:

What do you think?

For the documentation browser i would need exactly that, if a user selects a package and a documentation and language, the package key is a parameter in the URL, so the URL is like "/help/FLOW3/Manual/en" and the files of the documentation are passed through with the URL "/help/FLOW3/Manual/en/index.html". I could solve that with query parameters but with the routes it just works perfectly with the relative links in the documentation (without any prefixing). So I would like to have ugly URLs now, but parameters working. And in the long-term configurable case-insensitive route parts.

Christopher Hlubek wrote:

For the documentation browser i would need exactly that, if a user selects a package and a documentation and language
the package key is a parameter in the URL

you can use

$this->packageManager->getCaseSensitivePackageKey()

$this->objectManager->getCaseSensitiveObjectName()

Bastian Waidelich wrote:

Does that help?

Thanks, Absolutely! I haven't seen that before. But it's somewhat hacked into the PackageManager, I will have to change some other methods too.

Nevertheless we should clearly document, that parameters in URLs get lowercased.

Christopher Hlubek wrote:

Nevertheless we should clearly document, that parameters in URLs get lowercased.

Yep, will do. Thanks