使用前端控制器和 IIS 提供静态文件的方法？

Question

背景

IIS ISAPI 过滤器将所有请求路由到前端控制器 Java CMS 进行响应。没有物理文件对应于给定的 URL。动机：

1. 保护 URL
2. 实施 SSL

这是服务静态文件（例如音频和视频）的性能瓶颈。并且，池化的应用程序服务器处理线程被占用来服务响应。

想法

让应用程序服务器填充一个 IIS ISAPI 过滤器或 httpmodule，它可以读取文件，然后提供文件服务。可能使用物理文件路径、内容长度和 MIME 类型填充响应标头。

问题

1. 没有让 IIS 直接提供文件服务是错误的设计决策吗？如果是这样，请提供有关在安全性和 SSL 实施方面应注意哪些方面的建议（CMS 处理这两个方面）。
2. 如果让 IIS 响应，如何利用 IIS 静态文件缓存？或者说缓存有多大好处？

Answer 1

我认为您应该允许 IIS 提供静态文件。您可以让 HttpModule（或您的过滤器）将控制权转移回 IIS - 这意味着可能必须复制安全强制代码。另一种方法是让应用程序服务器将控制权转移回 IIS 来提供文件服务（安全检查当然会在之前进行）。或者最后，正如您所概述的，您的应用程序服务器可以注入响应标头，然后 httpmodule 会读取它们并将控制权传递给 IIS。不确定java，但在.NET中你可以使用 HttpResponse.TransmitFile 方法将控制权传回 IIS - 这应该避免需要使 HttpModule 提供文件。

最后，对于缓存，您始终可以发出缓存标头以响应较低级别（代理或客户端缓存）。如果文件正在更改，那么您可以添加文件依赖项等。

编辑：不确定这是否适合您。创建一个 http 处理程序 (ashx) 并将其标记为 IIS 中所需的 SSL。所有媒体文件都将由该处理程序提供服务。该处理程序将把文件作为查询参数。现在，您可以传递一些文件标识符或加密的部分路径（相对于文件存储的配置基本路径），以便用户看不到实际的文件名或路径。您甚至可以制作将在一段时间后过期的令牌（本质上是附加文件 ID 和时间戳并对其进行加密），以便用户无法使用相同的参数再次请求相同的文件。处理程序的伪代码是

void ProcessRequest(HttpContext context)
{
    // read file id/name token
    var token = context.Request["q"];

    // validate/decrypt token etc and get the actual path for file to be served
    string filePath;

    // set needed response headers - content-type, content-disposition and cache related
    ...

    // ask IIS to serve the file
    context.Response.TransmitFile(filePath);
}

Answer 2

这可能有效：

http://www.helicontech.com/ape/

特别是 x-sendfile 部分。