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

Question

背景

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

1. 保护 URL
2. 实施 SSL

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

想法

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

问题

1. 不让 IIS 直接提供文件的错误设计决定？如果是这样，请提供有关安全和 SSL 实施方面的建议（CMS 处理这两者）。
2. 如果要让 IIS 响应，如何利用IIS static file caching？或者缓存有多少好处？

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 片段。