htaccess 文件正确检测根目录中丢失的文件,但未检测到丢失的子目录
我有一个 .htaccess 文件,当请求的图像不存在时,我用它来捕获,以便我可以制作一个。当从 .htaccess 文件所在的目录请求时,该文件可以正确检测到丢失的图像。但是,如果我从技术上不存在的子目录请求图像,.htaccess 不会将我发送到我的图像处理程序。有人可以帮我匹配任何不存在的子目录吗?
这是我的 htaccess:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} .(jpg|jpeg|gif)$
RewriteRule ^(.*)$ missingimage.php?img=$1 [QSA,L]
该 .htaccess 文件放置在名为“uploads”的文件夹中。例如,我的上传文件夹也有 Oranges.jpg。
以下网址将正确地将请求传递给missingimage.php:
以下网址不正确地将请求传递给missingimage.php,而是从apache返回标准404:
如何修改我的 htaccess 来捕获请求不存在的目录并仍然将它们传递给我的图像处理程序?谢谢。
I have an .htaccess file that I'm using to catch when a requested image doesn't exist so I can make one. The file properly detects a missing image when requested from the directory the .htaccess file is in. But, if I request an image from a subdirectory that technically does not exist, .htaccess does not send me to my image handler. Can someone help me match any subdirectory that does not exist?
Here is my htaccess:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} .(jpg|jpeg|gif)$
RewriteRule ^(.*)$ missingimage.php?img=$1 [QSA,L]
That .htaccess file is placed in a folder called "uploads". So for example, my uploads folder also has oranges.jpg.
The following url will correctly pass the request to missingimage.php:
The following url will NOT correctly pass the request to missingimage.php, but instead returns a standard 404 from apache:
How can I modify my htaccess to catch requests to directories that don't exist and still pass them to my image handler? Thank you.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果请求不存在,REQUEST_FILENAME 实际上并不包含完整的绝对路径。我的理论是,在没有实际深入研究 httpd 核心代码的情况下,它认为我们已经足够了解该请求实际上并不存在,所以让我们停止寻找。
即,如果您请求 /uploads/fake/test.jpg ,它将 REQUEST_FILENAME 包含 /path/to/uploads/fake 并且实际上不会继续在那里附加 /test.jpg ,但当您执行 /path/to/ 时会这样做uploads/test.jpg 因为 test.jpg 是它知道请求不存在的终止位置。即使这不是 httpd 停止该字符串的原因,您也有很多其他变量可以帮助您。
这种重写条件:
现在对于为 MVC 框架创建调度程序的技巧非常流行,并且确实有效,因为 /path/to/uplaods/fake 既不是文件也不是目录,并且会将您的请求发送到图像调度程序。
这是扩展匹配条件的真正修复...您需要获取 REQUEST_URI,因为它将包含用户实际请求的内容 (/uploads/fake/test.jpg),包括文件扩展名,您可以在第三个 RewriteCond 中使用它以匹配文件扩展名。由于我们要将其用于第三条规则,因此我清理了前两条规则以进行匹配。
我清理了你在文件名上的匹配,因为你正在将各种废话与前导句点相匹配,这实际上是(在未转义时)告诉 preg 匹配引擎匹配任何内容。因此,反斜杠句点将使 preg 匹配实际的句点。
我还清理了请求 uri 的前半部分的匹配,以包含 /alpha/num/directories_with/underscores-and-dashes/followed/by/alpha-num_filenames.jpg|jpeg|gif,如果您愿意,请随意删除它不想要它。
REQUEST_FILENAME doesn't actually contain the full absolutely path if the request doesn't exist. My theory on this without actually digging into httpd core code would be that it's thinking we've come far enough to know that the request isn't actually there so let's stop looking.
i.e. if you request /uploads/fake/test.jpg it'll REQUEST_FILENAME contains /path/to/uploads/fake and won't actually continue to append /test.jpg on there, but does when you do /path/to/uploads/test.jpg because test.jpg is the termination of where it knows the request doesn't exist. Even if this isn't the reason why httpd stops the string there you have plenty of other variables that can help you.
This rewrite condition:
is ridiculously popular right now for this trick of creating a dispatcher for MVC frameworks and does actually work, since /path/to/uplaods/fake is niether a file nor a directory and will send your request to your image dispatcher.
Here's the real fix for your extension matching condition... you need to get the REQUEST_URI because it will contain what the user actually requested (/uploads/fake/test.jpg) including the file extension and you can us it in your third RewriteCond to match the file extension. Since we're going to use that for the third rule, I cleaned up your first two to match.
I cleaned up your match on the file name as you were matching all sorts of bullshit with that leading period which is actually (when un-escaped) telling the preg match engine to match anything. So, backslash period will make preg match an actually period.
I also cleaned up the match on the first half to the request uri to include /alpha/num/directories_with/underscores-and-dashes/followed/by/alpha-num_filenames.jpg|jpeg|gif, feel free to remove that if you don't want it.