Question

背景

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

保护网址
执行SSL

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

观

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

问题

错误的设计决定没有IIS直接提供文件？如果是这样，建议在安全性和SSL实施方面考虑什么（CMS处理两者）。
如果让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片段。

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

2 个答案: