Feature #2237

URLs can only be lowercase

Added by Sebastian Kurfuerst about 12 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Must have
Category:
MVC
Start date:
2008-11-27
Due date:
% Done:

100%

Estimated time:
PHP Version:
Has patch:
Complexity:

Description

Hello,

I cannot use upper-cased URLs in case I want to.

I just had a route configuration like:

Mapping_CRUD_RenderingGroupHelpers:
uriPattern: '[@package]/[@controller]/[@action]/id/[id]/renderingItem/[renderingItemId]'
defaults:
@controller: Default
@action: index
@format: html

(note the big "I" in renderingItem).

What happens is that it lowercases the URL during link generation, then you click onto the link, and see the DefaultView of FLOW3, appearently because no route matched... :-(

It'd be really nice to have uppercase URLs if you want them as well. Is there a reason this is prohibited?

Greets, and thanks,
Sebastian


Files


Related issues

Related to TYPO3.Flow - Task #1253: Enable lower case URLsResolvedRobert Lemke2008-08-08

Actions
Related to TYPO3.Flow - Bug #5182: Routing: @action should not be case sensitiveResolvedKarsten Dambekalns2009-10-30

Actions
#1

Updated by Karsten Dambekalns almost 12 years ago

  • Status changed from New to Accepted
  • Assignee changed from Bastian Waidelich to Karsten Dambekalns
Two ways to solve this:
  • make generated URIs have the case they should have according to the route configuration
  • match case-insensitive

The first seems cleaner, but in case of routing one would probably never want to distinguish between 'parts/Wheels' and 'parts/wheels'. I'd say, go for case-insensitive matching.

That would mean to change the StaticRoutePart, as it's the only place where this is needed.

#2

Updated by Karsten Dambekalns almost 12 years ago

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
#3

Updated by Robert Lemke over 11 years ago

  • Target version set to 283
#4

Updated by Christopher Hlubek over 11 years ago

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.

#5

Updated by Karsten Dambekalns over 11 years ago

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;
     }

#6

Updated by Bastian Waidelich over 11 years ago

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!

#7

Updated by Christopher Hlubek over 11 years ago

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.

#8

Updated by Karsten Dambekalns over 11 years ago

  • Assignee changed from Karsten Dambekalns to Bastian Waidelich

Christopher Hlubek wrote:

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

True. I hope Bastian has though of this already... :)

#9

Updated by Christopher Hlubek over 11 years ago

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.

#10

Updated by Bastian Waidelich over 11 years ago

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!

#11

Updated by Christopher Hlubek over 11 years ago

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.

#12

Updated by Bastian Waidelich over 11 years ago

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()

and
$this->objectManager->getCaseSensitiveObjectName()

to get the cased names just like the F3\FLOW3\MVC\Request does it to retrieve package & controller from the URI.
Does that help?

#13

Updated by Christopher Hlubek over 11 years ago

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.

#14

Updated by Bastian Waidelich over 11 years ago

Christopher Hlubek wrote:

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

Yep, will do. Thanks

#15

Updated by Robert Lemke over 11 years ago

  • Priority changed from Should have to Could have
  • Target version changed from 283 to 1.0 alpha 2
#16

Updated by Robert Lemke over 11 years ago

  • Target version changed from 1.0 alpha 2 to 283
#17

Updated by Robert Lemke over 11 years ago

  • Priority changed from Could have to Must have
#18

Updated by Robert Lemke over 11 years ago

  • Target version deleted (283)
#19

Updated by Robert Lemke over 11 years ago

  • Tracker changed from Bug to Feature
#20

Updated by Bastian Waidelich about 11 years ago

Karsten Hachmeister: Can you please apply the patch if you have no objections? I wasn't sure whether to commit this before alpha 6 release - The change should be backwards compatible though!

#21

Updated by Bastian Waidelich about 11 years ago

Bastian Waidelich wrote:

The change should be backwards compatible though!

I correct myself. The v2 should be backwards compatible.

#22

Updated by Karsten Dambekalns about 11 years ago

  • Target version set to 1.0 alpha 6
#23

Updated by Karsten Dambekalns about 11 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100

Applied in changeset r3382.

Also available in: Atom PDF