我以前从来没有见过这样的情况，Google迄今为止没有任何结果。 我几乎肯定这是一个愚蠢的错误，我应该看到它，但我不知道。
我有一个非常基本的Apache服务器与PHP，它服务于PHP文件好多年，没有问题。 不过，我刚刚发现，如果在URL中的.php之后添加%20 （例如https://www.example.com/index.php%20 ），则Apache将以纯文本forms提供文件而不是服务一个404页面。
我的PHP模块的conf似乎很好，我真的找不到任何信息时，谷歌search的问题。
我的/etc/apache2/mods-enabled/php5.conf内容
<IfModule mod_php5.c> AddType application/x-httpd-php .php .phtml .php3 AddType application/x-httpd-php-source .phps </IfModule>
Apache版本是2.2.22在Debian Wheezy上运行
任何人都见过这种情况，知道我必须调整什么魔术设置来阻止Apache这样做，而是服务于一个404页面？
试试这个，用这个replace你的当前版本：
<FilesMatch ".+\.ph(p[345]?|t|tml)$"> SetHandler application/x-httpd-php </FilesMatch>
然后重新启动Apache，看看是否修复它。 我不知道会不会，我猜想是不会的，但试试看，这是一个更精确的规则。
但它看起来像我在Apache的东西是不正确的处理与空间的url，我testing了这个在我的本地系统只是为了看到，当我要求：
"mysite.com/test.php "
Apache正确地在内部重写它
"mysite.com/test.php"
所以我相信几乎可以肯定另一种configuration是closures的。 但尝试以上，看看。
确保首先评论你的东西，然后加上这个。2.2中可能有语法差异，因为我正在运行apache 2.4，如果我记得正确的在debianconfiguration中有一些小的差异导致了很多问题，但我不记得他们是什么。
我相信你可以从这个完全排除PHP，这个问题似乎与apache2.2和它是如何处理url，我有这个Apache安装很长一段时间，我知道我没有添加或删除任何configuration会造成这种情况，所以您可能要仔细查看自安装以来可能做出的任何其他非phpconfiguration更改。
有一次，我看到在页面上的非parsingforms的PHP代码总是由于PHP引擎实际上没有正确configuration，但这不是你的情况，因为这只发生在.php之后的空间，所以你的PHP本身很好。
作为一个短期的黑客，但不是一个解决scheme，你可以做一个重写规则，这很简单：
RewriteRule ^(.*)([[:space:]]|%20)+$ /$1 [R=301,L]
我无法testing这个，因为我没有任何apache未能处理空格/％20在url的末尾，我也不知道如何做到这一点。
该规则简单地说，采取所有空格在行的末尾，转储他们，并redirect到实际的url。 请注意，有可能有更好的方法来做到这一点，这不是我遇到过的情况，所以我不知道最佳实践。