“本地 WAMP 服务器上包含 ':' 的路由中存在格式错误或无效字符的 Apache 错误”

Question

我正在使用 Apache 在 WAMP 服务器上本地运行 Slim Framework 项目。在某些包含 : 字符的路由（例如 /slicitudes:nuevo）中，我在 Apache 日志中收到以下错误： (20024)给定路径格式错误或包含无效字符：AH00127：无法映射 GET /slicitudes:nuevo 我尝试了各种解决方案，包括使用AllowEncodedSlashes NoDecode更新.htaccess文件以及使用RewriteRule重写路线，但似乎没有任何效果。这个错误只发生在我的本地环境（WAMP with Apache 2.4）上，而在其他环境上工作正常。

如何在不更改实际应用程序 URL 的情况下处理此路由？

我尝试了以下解决方案来解决包含 : 字符的路由问题：

将AllowEncodedSlashes NoDecode添加到.htaccess：

预期：允许 Apache 正确处理带有编码斜杠的路由。 结果：遇到内部服务器错误，因为 .htaccess 中不允许使用此指令。 将AllowEncodedSlashes NoDecode 移至httpd-vhost.conf：

预期：配置 Apache 以允许在全局 URL 中使用编码斜杠。 结果：路径格式错误的问题仍然存在，并且错误日志显示 Apache 无法映射路由。 重写.htaccess中的路线：

重写规则：RewriteRule ^slicitudes:nuevo$ solicitudes-nuevo [PT,L] 预期：使用 : 将路由重写为 Apache 可以处理的格式。 结果：错误仍然存在，表明路由格式仍然错误或包含无效字符。 尽管进行了这些尝试，问题仍然没有解决，并且仅发生在我的 WAMP 设置上本地。

Answer 1

WAMP - Windows。 “问题”是

:

（冒号）字符在 Windows 文件名中不是有效字符。这最终是 Windows 操作系统的限制。

当您向网络服务器（Apache）发出请求时，该请求将被映射到文件系统。正是在这一点上发生了错误（我预计会出现“403 Forbidden”响应）。不幸的是，

.htaccess

是在请求已映射到文件系统之后处理的，因此无法在

.htaccess

中解决。

AllowEncodedSlashes

与此处无关。该指令仅与允许 URL 的 URL-path/path-info 部分中的 URL 编码（正向）斜杠 (

%2F

) 和反斜杠 (

%5C

) 相关。

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

如上所述，尝试在

.htaccess

中解决此问题是行不通的（为时已晚）。然而，简单地“重写”对另一个任意 URL 的请求无论如何都不太可能起作用（框架不会看到重写的 URL - 尽管这可能是因为不同的 URL 将映射到文件系统的意图？）。 您可以尝试将现有的超薄前端控制器模式从

.htaccess

（

directory

上下文）移动到主服务器配置（或<VirtualHost>容器）。不是

<Directory>

容器（实际上与

.htaccess

相同 - 但在服务器中），因为它也运行得太晚了。这允许在请求映射到文件系统之前，将请求内部重写到前端控制器（即

index.php

）。但是，在将指令从 .htaccess （

directory

上下文）移动到主服务器块（

server

上下文）或 <VirtualHost> 容器（virtualhost 上下文）时，您需要修改指令，因为指令处理得更早（

在

请求映射到文件系统之前） 如果您的 .htaccess 文件当前如下所示：

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

来源：

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

那么在 server

上下文中使用时相应的指令将类似于：

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

（原始代码块中不需要

QSA

 标志。）

在

server

上下文中，

REQUEST_FILENAME

仍然包含请求的 URL（而不是文件名），因此尝试在 server 上下文中直接使用它来执行文件系统检查将始终失败。相反，从文档根目录和请求的 URL 路径手动构造文件名会更容易。