IIS7 重写模块和 ASP.net Request.PhysicalPath答案

【问题标题】：IIS7 Rewrite Module and ASP.net Request.PhysicalPathIIS7 重写模块和 ASP.net Request.PhysicalPath
【发布时间】：2012-03-06 04:52:09
【问题描述】：

我的任务是为客户创建面包屑功能。他们当前的网站设置为基于 XML/文件。每个 .aspx 页面的深度为 N 级，其中一个控件连接到其各自的 .xml 文件。

我决定通过页面目录结构来实现面包屑。我正在抓取物理路径，剥离根目录，拆分目录，并将这些部分用作我的面包屑。他们所有的文件夹都以 CamelCase 命名，所以我使用骆驼外壳来拆分单词以进行显示。

例如：网站可能看起来像

首页

-- 子目录 1

----- 子目录 1.1

--------- MyPage.aspx

-- 子目录 2

------MySecondPage.aspx

如果你在“MyPage.aspx”.. 你得到的面包屑是：

首页 -> 子目录 1 -> 子目录 1.1 -> 我的页面

这是我遇到的问题。客户端还使用 IIS7 重写模块来强制使用小写 URL。问题在于我在 Request.PhysicalPath 调用中返回的值都是小写的，所以我的显示文本不起作用（因为它依赖于 CamelCase）。如果我关闭 IIS7 强制，它显示如上。如果没有，我会得到：

首页 -> 子目录 1 -> 子目录 1.1 -> 我的页面

是否可以通过 IIS7 重写模块在不影响 Request.PhysicalPath（或 Request.PhysicalApplicationPath）调用的情况下强制使用小写 URL？

谢谢

【问题讨论】：

【解决方案1】：

我认为在这种情况下你不能依赖 Request.PhysicalPath。

尝试使用approach from this question 获取正确大小写的实际文件名

【讨论】：

完美。正是我要找的，你最好。作为一个后续问题，因为这个实现将用于构建面包屑，因此在每页的基础上调用，你认为每次循环访问 I/O 至少几次会产生什么影响，遍历循环至少几次（n 次对于 n 个深层目录级别），每个页面加载？
是否值得添加一个缓存机制来缓存格式化的路径信息并使用该值而不是每次都去文件系统？
没有测试很难预测性能。但是，在类似的情况下（当结果预计不会随时间变化时）我通常使用静态的 ConcurrentDictionary 或 HttpApplicationState 来存储结果，它易于实现并保证没有冗余 I/O。
好电话@Artem，这正是我最终所做的，它在生产中运行良好