为什么 IIS 7.5 在文件夹上添加尾部斜杠？我们可以禁用删除尾部斜杠的 URL 重写规则的礼貌重定向吗？
IIS 通过添加尾部斜杠来对目录进行 URL 清理。请参阅 IIS 6 中的旧文档： 当请求没有尾部斜杠的文件夹时，IIS 会生成礼节性重定向
- 为什么？意图仍然相关吗？
- 有任何安全隐患吗？
- 如何禁用它以使其与 URL 重写规则“RemoveTrailingSlashRule”一起使用
当您使用 URL 重写 2 在 IIS 7.5 下添加规则时，该规则将不会应用于目录（使用 IsDirectory）和文件夹（使用 IsFolder）。
请参阅添加规则以附加或删除尾部斜杠符号上的此警告：
这将创建RemoveTrailingSlashRule1：
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我在这里有一个针对子 IIS 应用程序具体情况的答案：https://stackoverflow.com/a/25817317/292060。子应用程序似乎是通常的罪魁祸首，但在这个问题中没有明确描述。
为了尝试回答这些问题，以下是我多年来与 IIS 和 Microsoft 打交道的观点。我没有可靠的资料来源可以引用；其中一些只是直觉。
我认为它源于最初的“默认文档”功能，即index.html。网站希望他们的主页只是域名，然后扩展到子文件夹。通过 url 重写，意图不再相关 - 您可以重写您想要的内容，并且宁愿 IIS 滚开。通常需要友好的 url，并且没有尾随斜杠（域/网站根目录除外 - 需要有尾随斜杠，即使某些浏览器（如 Chrome）变得可爱并隐藏它）。
我认为唯一的安全隐患是原始目录浏览。如果您忘记执行默认文档，并且目录浏览处于打开状态，那么人们就可以浏览您的网站文件。据我所知，目录浏览作为默认设置早已被禁用。
对于任何请求，无论是否尾部斜杠、URL 重写与否，您的服务器和代码都需要承受不良请求。这适用于所有情况，而不仅仅是针对斜杠。 http://xkcd.com/327/
如果问题是子应用程序，我有一个答案，此处：https://stackoverflow.com/a/25817317/292060
摘要是，在 IIS 中：
如果此问题是针对更一般的问题，包括常规子文件夹，即使不是子应用程序，请考虑从中删除“不是目录”规则，并让其重定向，即使它看到一个目录。我不确定这可能有效，或者可能会创建无限重定向循环。
I have an answer for the specific case of a child IIS Application here: https://stackoverflow.com/a/25817317/292060. The child app seems to be the usual culprit, but isn't explicitly described in this question.
To try to answer the questions, here are my opinions from dealing with IIS and Microsoft for years. I don't have hard sources to cite; some of this is just gut feelings.
I think it stemmed from the original "default document" feature, namely index.html. Websites wanted their home page to just be the domain, then this extended to subfolders. With url rewriting, the intent isn't relevant anymore - you can rewrite to your heart's content, and would rather IIS get out of the way. It's common to want friendly urls, and no trailing slash (except for the domain/website root - that is required to have a trailing slash, even if some browsers like Chrome get cute and hide it).
I think the only security implication was the original directory browsing. If you forgot to do a default document, and directory browsing was left turned on, then people could browse your website files. As far as I know, directory browsing has been long disabled as the default setting.
With any requests, whether trailing slash or not, url rewriting or not, your server and code need to withstand bad requests. This is true for all situations, not just specific to the slashes. http://xkcd.com/327/
I have an answer if the issue is the child application, here: https://stackoverflow.com/a/25817317/292060
The summary is, in IIS:
If this question is for a more general issue, including regular subfolders even if not a child app, consider removing the "Is Not a Directory" from the rule, and let this redirect even when it sees a directory. That may work, or may create an infinite redirect loop, I'm not sure.
这拯救了我们：
为了帮助我们在谷歌中索引我们的 Angular 17 SSR 网站，因为它会生成一个与路由同名的文件夹。设置
to false 结合重写规则就成功了
This saved us:
To help us indexing our Angular 17 SSR website in google, because It generates a folder with the same name as the route. Setting the
to false in combination of the rewrite rule did the trick