c# - 继承了一个具有 60,000 个 url 重定向的 ASP.NET 网站应用程序

Question

不是开玩笑.. 使用 IIS 插件 UrlRewrite，我们正在运行一个推送 8mb 的 map 配置。它包含 60,000 个“从 -> 到”规则条目。配置文件太大，我们必须调整注册表以适应配置文件的大小。

重定向主要包括:

1. .html -> .aspx during a migration to asp.net
2. pages that have been renamed
3. short lived campaigns redirecting back to the home page
4. and all the redirects are replicated 18 times, one for each language folder such as /us/, /uk/, etc.

我们正准备大幅减少重定向的数量，所以这不是我关心的问题。我担心的是每周大约 3-4 个新的重定向请求。手动将重定向条目添加到配置文件并传播到生产服务器变得乏味且耗时。

正在讨论的是，将 60,000 次重定向视为“遗留重定向”，并将在单独的线程中减少。对于所有 future 的重定向，内容编辑器将创建与包含 Response.Redirects 到“To”地址的“From”url 模式相匹配的文件。

我对这种方法感到震惊，因为我们将拥有大量使用 UrlRewrite 的重定向和越来越多的散布在整个网站上的单行重定向文件。我预测一场史诗般的灾难。最糟糕的是我想不出更好的解决方案。

我想问大家的问题是，管理像这样一个不断变化的大型网站的重定向的最佳做法是什么？是否有一种 .net 技术恰好适合这种困境？

Answer 1

我会完全放弃大量重定向。谈论一场噩梦。只需在正确的路径上提供您想要访问的页面。

如果您收到对不存在的页面的请求，而不是显示 404 Not Found，让网络服务器通过在数据存储中查找匹配的“新目标”来处理请求(这可以完成带有特殊的 ASP 页面)。您的数据存储将包含旧到新的映射，如果存在一个匹配项，用户将被重定向。如果不是，则显示真正的 404(以及一条善意的消息给用户以更新他们的链接)。

这让您摆脱编写大量重写规则的工作，并将旧到新映射的管理放入数据库中，为什么不呢! :)

希望这有助于产生新的想法...