好的，那么第二个问题首先出现：
为什么区分大小写会带来安全风险？
区分大小写本身并不是安全风险。根据另一个答案中的注释，问题似乎在于它可能绕过具有特定名称/大小写的目录（特别是）
WEB-INF（可能包含敏感代码或配置文件）上的安全约束。
如果您尝试访问domain.com/WEB-INF，则Tomcat将阻止该访问，同时将domain.com/Web-
Inf视为不同，并且可能不会阻止该访问（我尚未实际测试过是否是这种情况） 。
但是，这并不是真正的问题，因为Railo不需要您在webroot内拥有WEB-INF目录-
您可以将Railo配置为指向其他位置，如果该位置不在webroot内，则可以解决此问题。
（免责声明：这是基于可用的信息；它可能不止于此，但是您有责任对任何可公开访问的网站执行安全扫描/渗透测试。）
如何解决区分大小写的问题？
这里有很多选择…
考虑使用另一个servlet引擎而不是Tomcat，例如Jetty。
Jetty和Tomcat的情况相同，但不赞成使用Jetty的
aliases选项（在中
{jetty}/etc/webdefault.xml）（就像Tomcat的区分大小写的开关一样），在简短的测试中，它似乎阻止了对所有大小写变体的访问web-inf。
可能还有其他的servlet引擎具有可以接受的类似选项（例如Resin
将Railo与Tomcat一起使用时，无需删除Web服务器。
虽然您 可以 使用Tomcat的Coyote Web服务器，但不需要这样做，并且将Apache
httpd，Nginx或IIS7放在前面可以为您提供更大的灵活性-特别是，它可以使静态资源不区分大小写。
我说这是因为您提供的示例是一个图像文件，所以它不需要转到servlet引擎或Railo-
如果只有静态文件成为问题（如果所有请求都通过index.cfm，则完全有可能），那么简单地将Web服务器配置为不区分大小写是解决此问题的一种简单方法，而无需使用Tomcat
/ Railo。
修复文件时要使用一致的大小写，使用URL重写来重定向请求。
例如，在记录404错误时抓取您的网站-这将为您提供大小写不匹配的列表。
完成此操作后，创建一个简单的脚本将所有这些文件重命名为小写，并生成一系列重写规则，以便将请求的文件重定向到小写变体。
例如，使用mod_rewrite语法：
# If file exists, don't rewrite it (and stop processing further rules)RewriteCond ${REQUEST_URI} !fRewriteRule .* - [L]# Requested file doesn't exist, so redirect to lowercase versionRewriteRule (?i)img/employee/greg.jpg img/employee/greg.jpg [L,R=301]RewriteRule (?i)img/employee/bert.jpg img/employee/bert.jpg [L,R=301]RewriteRule (?i)whatever.else whatever.else [L,R=301]第一条规则确保不需要检查存在的文件（L标志说停止寻找进一步的重定向），而（？i）将执行不区分大小写的匹配并执行301重定向到正确的文件。
这解决了眼前的问题，随着时间的推移，您可以逐渐更新代码以使用一致的大小写，直到不再需要重定向为止。
重写语法随Web服务器使用的内容而有所不同-所有选项都有选项，但有些选项比其他选项更成熟/集成。
