ASP.NET Core应用针对静态文件请求的处理[5]: DefaultFilesMiddleware中间件如何显示默认页面-低调大师

ASP.NET Core应用针对静态文件请求的处理[5]: DefaultFilesMiddleware中间件如何显示默认页面

2017-10-23 562

DefaultFilesMiddleware中间件的目的在于将目标目录下的默认文件作为响应内容。我们知道，如果直接请求的就是这个默认文件，那么前面介绍的StaticFileMiddleware中间件会将这个文件响应给客户端。如果我们能够将针对目录的请求重定向到这个默认文件上，一切就迎刃而解了。实际上DefaultFilesMiddleware中间件的实现逻辑很简单，它采用URL重写的形式修改了当前请求的地址，即将针对目录的URL修改成针对默认文件的URL。[本文已经同步到《ASP.NET Core框架揭秘》之中]

我们照例先来看看DefaultFilesMiddleware类型的定义。和其他两个中间件类似，DefaultFilesMiddleware的构造就有一个IOptions<DefaultFilesOptions>类型的参数来指定相关的配置选项。由于DefaultFilesMiddleware中间件本质上依然体现了请求路径与某个物理目录的映射，所以DefaultFilesOptions依然派生于SharedOptionsBase。DefaultFilesOptions的DefaultNames属性包含了预定义的默认文件名，我们可以看到它默认包含四个名称（default.htm、default.html、index.htm或者index.html）。

   1: public class DefaultFilesMiddleware

   2: {

   3:     public DefaultFilesMiddleware(RequestDelegate next, IHostingEnvironment hostingEnv, IOptions<DefaultFilesOptions> options);

   4:     public Task Invoke(HttpContext context);

   5: }

6:

   7: public class DefaultFilesOptions : SharedOptionsBase

   8: {

   9:     public IList<string> DefaultFileNames { get; set; }

10:

  11:     public DefaultFilesOptions() : this(new SharedOptions()){}

  12:     public DefaultFilesOptions(SharedOptions sharedOptions) : base(sharedOptions)

  13:     {

  14:         this.DefaultFileNames = new List<string> { "default.htm", "default.html", "index.htm", "index.html" };

  15:     }

  16: }

我们同样采用一种比较易于理解的形式重新定义这个DefaultFilesMiddleware类型以便于读者朋友理解它具体采用的请求处理逻辑。如下面的代码片段所示，DefaultFilesMiddleware和DirectoryBrowserMiddleware一样会对请求做相应的验证。如果当前目录下存在某个默认文件，那么它会将当前请求的URL修改成指向这个默认文件的URL。值得一提的是，DefaultFilesMiddleware中间件要求访问目录的请求路劲必须以字符“/”作为后缀，否则会在目前的路径上添加这个后缀并针对最终的路径发送一个重定向。

   1: public class DefaultFilesMiddleware

   2: {

   3:     private RequestDelegate         _next;

   4:     private DefaultFilesOptions     _options;

5:

   6:     public DefaultFilesMiddleware(RequestDelegate next, IHostingEnvironment env, IOptions<DefaultFilesOptions> options)

   7:     {

   8:         _next                     = next;

   9:         _options                  = options.Value;

  10:         _options.FileProvider     = _options.FileProvider ?? env.WebRootFileProvider;

  11:     }

12:

  13:     public async Task Invoke(HttpContext context)

  14:     {

  15:         //只处理GET和HEAD请求

  16:         if (!new string[] { "GET", "HEAD" }.Contains(context.Request.Method,StringComparer.OrdinalIgnoreCase))

  17:         {

  18:             await _next(context);

  19:             return;

  20:         }

21:

  22:         //检验当前路径是否与注册的请求路径相匹配

  23:         PathString path = new PathString(context.Request.Path.Value.TrimEnd('/') + "/");

  24:         PathString subpath;

  25:         if (!path.StartsWithSegments(_options.RequestPath, out subpath))

  26:         {

  27:             await _next(context);

  28:             return;

  29:         }

30:

  31:         //检验目标目录是否存在

  32:         if (!_options.FileProvider.GetDirectoryContents(subpath).Exists)

  33:         {

  34:             await _next(context);

  35:             return;

  36:         }

37:

  38:         //检验当前目录是否包含默认文件

  39:         foreach (var fileName in _options.DefaultFileNames)

  40:         {

  41:             if (_options.FileProvider.GetFileInfo($"{subpath}{fileName}").Exists)

  42:             {

  43:                 //如果当前路径不以"/"作为后缀，会响应一个针对“标准”URL的重定向

  44:                 if (!context.Request.Path.Value.EndsWith("/"))

  45:                 {

  46:                     context.Response.StatusCode = 302;

  47:                     context.Response.GetTypedHeaders().Location = new Uri(path.Value + context.Request.QueryString);

  48:                     return;

  49:                 }

  50:                 //将针对目录的URL更新为针对默认文件的URL

51:

  52:             }

  53:         }

  54:         await _next(context);

  55:     }

  56: }

正是因为DefaultFilesMiddleware中间件采用URL重写的方式来响应默认文件，所以它最终依赖StaticFileMiddleware中间件来响应默认文件，所以针对后者的注册时必须的。也正是这个原因，这个中间件需要优先注册以确保URL重写发生在StaticFileMiddleware响应文件之前。

ASP.NET Core应用针对静态文件请求的处理[1]: 以Web的形式发布静态文件
 ASP.NET Core应用针对静态文件请求的处理[2]: 条件请求与区间请求
 ASP.NET Core应用针对静态文件请求的处理[3]: StaticFileMiddleware中间件如何处理针对文件请求
 ASP.NET Core应用针对静态文件请求的处理[4]: DirectoryBrowserMiddleware中间件如何呈现目录结构
 ASP.NET Core应用针对静态文件请求的处理[5]: DefaultFilesMiddleware中间件如何显示默认页面

作者：蒋金楠
微信公众账号：大内老A
微博： www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

原文链接

微信关注我们

原文链接：https://yq.aliyun.com/articles/226303

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

用PyTorch还是TensorFlow？斯坦福大学CS博士生带来全面解答

关于深度学习的框架之争一直没有停止过。PyTorch，TensorFlow，Caffe还是Keras ？近日，斯坦福大学计算机科学博士生Awni Hannun就发表了一篇文章，对比当前两个主流框架PyTorch和TensorFlow。雷锋网 AI 科技评论编译如下：这篇指南是我目前发现的PyTorch和TensorFlow之间的主要差异。写这篇文章的目的是想帮助那些想要开始新项目或者转换深度学习框架的人进行选择。文中重点考虑训练和部署深度学习堆栈组件时框架的可编程性和灵活性。我不会权衡速度、内存使用情况等性能。结论 PyTorch更适合于在研究中快速进行原型设计、业余爱好者和小型项目，TensorFlow则更适合大规模的调度，尤其当考虑到跨平台和嵌入式调度操作时。准备时间优胜者: PyTorch PyTorch实际上是NumPy的替

2017-10-24

674

我们通过《以Web的形式发布静态文件》和《条件请求与区间请求》中的实例演示，以及上面针对条件请求和区间请求的介绍，从提供的功能和特性的角度对这个名为StaticFileMiddleware的中间进行了全面的介绍，接下来我们将更近一步，将从实现原理的角度来进一步认识这个中间件。 [本文已经同步到《ASP.NET Core框架揭秘》之中] 目录一、StaticFileMiddleware 二、ContentTypeProvider 三、利用配置指定StaticFileOptions 四、实现原理一、StaticFileMiddleware 不过在此之前，我们先来看看StaticFileMiddleware这个类型的定义。 1: publicclass StaticFileMiddleware 2: { 3: public StaticFileMiddleware(RequestDelegate next, IHostingEnvironment hostingEnv, IOptions<StaticFileOptions> options, ILoggerFactory l...

2017-10-24

495

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。