本文共 21640 字，大约阅读时间需要 72 分钟。
我们通过《》和《》中的实例演示，以及上面针对条件请求和区间请求的介绍，从提供的功能和特性的角度对这个名为StaticFileMiddleware的中间进行了全面的介绍，接下来我们将更近一步，将从实现原理的角度来进一步认识这个中间件。 [本文已经同步到《》之中]
目录
一、StaticFileMiddleware 二、ContentTypeProvider 三、利用配置指定StaticFileOptions 四、实现原理
不过在此之前，我们先来看看StaticFileMiddleware这个类型的定义。
1: public class StaticFileMiddleware
2: { 3: public StaticFileMiddleware(RequestDelegate next, IHostingEnvironment hostingEnv, IOptionsoptions, ILoggerFactory loggerFactory);
4: public Task Invoke(HttpContext context);
5: }
如上面的代码片段所示，除了作为“下一个中间件”的next参数之前，StaticFileMiddleware的构造函数还包含三个参数。其中hostingEnv和loggerFactory这两个参数分别表示当前执行环境和用来创建Logger的工厂，最重要的options参数表示为这个中间件指定的配置选项，至于具体可以提供怎样的配置选项，我们只需要看看 StaticFileOptions这个类型提供了怎样的属性成员。
1: public class StaticFileOptions : SharedOptionsBase
2: { 3: public IContentTypeProvider ContentTypeProvider { get; set; } 4: public string DefaultContentType { get; set; } 5: public bool ServeUnknownFileTypes { get; set; } 6: public ActionOnPrepareResponse { get; set; }
7:
8: public StaticFileOptions();
9: public StaticFileOptions(SharedOptions sharedOptions);
10: }
11:
12: public abstract class SharedOptionsBase
13: { 14: protected SharedOptionsBase(SharedOptions sharedOptions);
15: public IFileProvider FileProvider { get; set; } 16: public PathString RequestPath { get; set; } 17: }
18:
19: public class SharedOptions
20: { 21: public IFileProvider FileProvider { get; set; } 22: public PathString RequestPath { get; set; } 23: }
24:
25: public class StaticFileResponseContext
26: { 27: public HttpContext Context { get; } 28: public IFileInfo File { get; } 29: }
如上面的代码片段所示，StaticFileOptions继承自抽象类型SharedOptionsBase，后者实际上体现的是两个路径之间的映射关系，一个是HTTP请求采用的路径，另一个则是文件的物理地址，后者体现为一个FileProvider对象。不过也正是因为文件的读取是通过这个FileProvider来完成的，而FileProvider未必就一定对应着具体的物理文件，所以StaticFileMiddleware并不限于针对专门处理“物理文件”。
直接定义在StaticFileOptions中的前三个类型都与媒体类型的解析有关，其中ContentTypeProvider属性返回一个根据请求相对地址进行媒体类型的ContentTypeProvider对象。如果这个ContentTypeProvider不能正确解析出目标文件的媒体类型，我们可以利用DefaultContentType设置一个默认媒体类型。但是只有将另一个名为ServeUnknownFileTypes的属性设置为True的情况下，媒体类型不能正常识别的请求采用使用这个默认设置的媒体类型。
StaticFileOptions还具有一个OnPrepareResponse属性，它返回一个Action<StaticFileResponseContext>类型的委托对象，我们可以为这属性指定的委托对象来对最终的响应进行定制。至于作为委托输入参数的是一个类型为StaticFileResponseContext的对象，我们利用它可以获得当前的HTTP上下文和目标文件。
针对StaticFileMiddleware这个中间件的注册一般都是调用针对ApplicationBuilder的UseStaticFiles扩展方法来完成的。具体来说，一共具有三个UseStaticFiles方法重载供我们选择，如下所示的代码片段展示了这三个扩展方法的实现。
1: public static class StaticFileExtensions
2: { 3: public static IApplicationBuilder UseStaticFiles(this IApplicationBuilder app)
4: { 5: return app.UseMiddleware();
6: }
7:
8: public static IApplicationBuilder UseStaticFiles(this IApplicationBuilder app,StaticFileOptions options)
9: { 10: return app.UseMiddleware(Options.Create (options));
11: }
12:
13: public static IApplicationBuilder UseStaticFiles(this IApplicationBuilder app, string requestPath)
14: { 15: StaticFileOptions options = new StaticFileOptions
16: { 17: RequestPath = new PathString(requestPath)
18: };
19: return app.UseStaticFiles(options);
20: }
21: }
StaticFileMiddleware针对物理文件请求的处理并不仅仅限于完成文件内容的响应，还需要针对文件的格式解析出正确的媒体类型。对于客户端来说，如果无法确定媒体类型，获取的文件就像是一步无法解码的天书，毫无意义。StaticFileMiddleware利用指定的ContentTypeProvider来解析媒体类型，ContentTypeProvider是我们对实现了IContentTypeProvider接口的所有类型以及对应对象的统称。如下面的代码片段所示，IContentTypeProvider接口定义了唯一的方法TryGetContentType根据当前请求的相对路径来解析这个作为输出参数的媒体类型。
1: public interface IContentTypeProvider
2: { 3: bool TryGetContentType(string subpath, out string contentType);
4: }
StaticFileMiddleware默认使用的ContentProvider是一个具有如下定义的FileExtensionContentTypeProvider对象。顾名思义，FileExtensionContentTypeProvider利用物理文件的扩展名来解析对应的媒体类型，它利用其Mappings属性表示的字典维护了一个扩展名与媒体类型之间的映射关系。我们常用的数百种标准的文件扩展名和对应的媒体类型之间的映射关系都会保存在爱这个字典中。如果我们发布的文件具有一些特殊的扩展名，或者我们需要现有的某些扩展名映射为不同的媒体类型，这些通过添加或者修改映射关系来实现。
1: public class FileExtensionContentTypeProvider : IContentTypeProvider
2: {