WAMP – Windows. The “problem” is that the : (colon) character is not a valid character in Windows filenames. This is ultimately a limitation of the Windows OS. (You do not get the same error on Apache/Linux.)

When you make a request to the webserver (Apache), the requested URL ultimately gets mapped to the filesystem. It is at this point the error occurs (which normally triggers a “403 Forbidden” response). Unfortunately, .htaccess is processed after the request has already been mapped to the filesystem, so this cannot be resolved in .htaccess.

However, this can be resolved if you have access to the main server (or Virtual Host) config. (Otherwise, you would need to change these URLs if you are using Apache on a Windows server.)

AllowEncodedSlashes is not relevant here. This directive is only to do with allowing URL encoded (forward) slashes (%2F) and backslashes (%5C) in the URL-path/path-info part of the URL.

RewriteRule ^solicitudes:nuevo$ solicitudes-nuevo [PT,L]

As mentioned above, attempting to resolve this in .htaccess is not going to work (it’s too late). However, simply rewriting the request to another arbitrary URL is unlikely to work anyway (the framework is not going to see the rewritten URL – although maybe that’s the intention as a different URL would be mapped to the filesystem?).

You could try moving the existing slim front-controller pattern from .htaccess (a directory context) to the main server config (or <VirtualHost> container). Not a <Directory> container (that’s effectively the same as .htaccess – but in the server) as that also runs too late. This allows the request to be internally rewritten to the front-controller (ie. index.php) before the request is mapped to the filesystem.

However, in moving the directives from .htaccess (a directory context) to either the main server block (server context) or <VirtualHost> container (virtualhost context) you need to modify the directives since the directives are processed much earlier (before the request is mapped to the filesystem)

If your .htaccess file currently looks like this:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^ index.php [QSA,L]

Source: https://www.slimframework.com/docs/v3/start/web-servers.html

Then the corresponding directives when used in a server context would be something like:

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/$1 !-f
RewriteCond %{DOCUMENT_ROOT}/$1 !-d
RewriteRule ^/(.+) /index.php [L]

(The QSA flag was unnecessary in the original code block.)

In a server context, REQUEST_FILENAME still contains the requested URL (not the filename), so attempting to use this directly in a server context to perform filesystem checks will always fail. Instead, it’s easier to manually construct the filename from the document-root and requested URL-path.