ASP.NET Core自定义URL重写匹配成功但返回空白页问题排查

你遇到的空白页、重写不生效问题由两个核心错误导致：

1. 中间件注册顺序完全错误
   ASP.NET Core 中间件严格按照Configure方法中的注册顺序执行，你当前将app.UseRewriter(options)放在了app.UseEndpoints之后。请求到达执行链时，会先经过路由匹配、Razor页面执行，等走到重写中间件时，响应已经开始生成，后续修改请求路径不会被已执行的路由/页面中间件感知，自然无法命中目标页面。
2. 自定义IRule实现逻辑错误

• 你在修改请求属性前就提前设置context.Result = RuleResult.EndResponse，该配置会直接终止整个中间件管道，后续的静态文件、Razor页面处理逻辑完全不会执行，必然返回空白响应。
• 错误将查询字符串拼接到request.Path属性中：request.Path仅存储请求路径部分，查询参数需要单独赋值给request.QueryString，拼接写法会导致路径匹配完全失败。
• 服务端URL重写（地址栏URL不变，内部转发到目标页面）不需要设置Location响应头，该头仅用于301/302客户端跳转场景。
• 重写同应用内路径不需要手动修改request.Host属性，多余配置反而会引发请求异常。

1. 调整中间件注册顺序 #

将重写中间件移动到路由匹配之前，正确的执行顺序参考如下代码：

public void Configure(IApplicationBuilder app, IWebHostEnvironment env, ILoggerFactory loggerFactory)
{
    app.UseWebOptimizer();
    app.UseStaticFiles();
    // 重写中间件必须放在UseRouting之前，确保路径修改在路由匹配前完成
    var options = new RewriteOptions().Add(new ProductPageRequests(Path.Combine(env.ContentRootPath, "mapfile.txt")));
    app.UseRewriter(options);
    
    app.UseRouting();
    app.UseSession();

    app.ConfigureStackifyLogging(Configuration);
    loggerFactory.AddStackify();
    app.ConfigureStackifyLogging(Configuration); 

    app.UseAuthentication();
    app.UseAuthorization();

    app.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

2. 修正自定义重写规则逻辑 #

修复提前终止管道、路径赋值错误的问题，同时补充MapFile加载逻辑匹配你的业务需求，参考代码如下：

public class ProductPageRequests : IRule
{
    // 启动时加载MapFile到内存字典，避免每次请求读文件
    private readonly IReadOnlyDictionary<string, string> _skuMap;
    public ProductPageRequests(string mapFilePath)
    {
        // 读取txt格式的MapFile，按行拆分存储url-sku映射关系
        var map = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
        foreach (var line in File.ReadLines(mapFilePath))
        {
            if (string.IsNullOrWhiteSpace(line)) continue;
            var parts = line.Split(new[] {' ', '\t'}, StringSplitOptions.RemoveEmptyEntries);
            if (parts.Length >=2)
            {
                map[parts[0]] = parts[1];
            }
        }
        _skuMap = map;
    }

    public void ApplyRule(RewriteContext context)
    {
        var request = context.HttpContext.Request;            
        string pattern = @"products/(.+)\.aspx";
        Regex r = new Regex(pattern, RegexOptions.IgnoreCase);
        Match match = r.Match(request.Path);
        if (match.Success)
        {
            // 提取匹配到的产品url标识，从Map中取对应SKU
            var productUrlKey = match.Groups[1].Value;
            if (!_skuMap.TryGetValue(productUrlKey, out var sku))
            {
                // 匹配不到sku可按需配置404逻辑，示例暂时给默认值
                sku = "1234";
            }
            // 仅修改路径和查询字符串，不要提前终止管道
            request.Path = "/ProductPage";
            request.QueryString = new QueryString($"?SKU={sku}").Add(request.QueryString);
            // 不需要修改Host，不需要设置Location头
            context.Result = RuleResult.SkipRemainingRules;
        }
    }
}

如果你需要实现客户端301永久跳转（地址栏显示新URL），才需要设置状态码和Location头，写法如下：

if (match.Success)
{
  var response = context.HttpContext.Response;
  response.StatusCode = StatusCodes.Status301MovedPermanently;
  response.Headers[HeaderNames.Location] = $"/ProductPage?SKU={sku}{request.QueryString}";
  context.Result = RuleResult.EndResponse;
}

• 服务端重写场景下，赋值给request.Path的路径必须以/开头，否则会出现路径解析错误。
• MapFile建议在应用启动时一次性加载到内存，不要在每次请求触发时读取文件，避免性能损耗。
• 调整顺序后可先在重写逻辑、ProductPage页面OnGet方法处加断点，确认请求路径修改后是否正常进入页面处理逻辑。

内容的提问来源于stack exchange，提问作者Swanand Mokashi