Подход Использование фронт-контроллера и IIS, обслуживающих статические файлы? - PullRequest
2 голосов
/ 13 декабря 2010

Фон

Фильтр IIS ISAPI направляет все запросы на внешний контроллер Java CMS для ответа. Ни один физический файл не соответствует данному URL. Мотивы:

  1. Защита URL-адресов
  2. Применение SSL

Это узкое место производительности, обслуживающее статические файлы, такие как аудио и видео. И потоки обработки сервера приложений в пуле заняты, обслуживая ответ.

Идея

Попросите сервер приложений заполнить IIS ISAPI Filter или httpmodule, который может читать и затем обслуживать файл. Возможно, заполните заголовок (и) ответа физическим путем к файлу, длиной содержимого и типом mime.

Вопросы

  1. Плохое дизайнерское решение, когда IIS не обслуживает файлы напрямую? Если это так, предложения по поводу безопасности и применения SSL (CMS обрабатывает оба).
  2. Если вы хотите получить ответ IIS, что нужно сделать, чтобы воспользоваться статическим кэшированием файлов IIS ? Или сколько пользы от кеша?

Ответы [ 2 ]

2 голосов
/ 13 декабря 2010

Я считаю, что вы должны разрешить IIS обслуживать статические файлы. У вас может быть HttpModule (или ваш фильтр), передающий элемент управления обратно в IIS - это означает, что может потребоваться репликация кода обеспечения безопасности. Еще один подход может заключаться в том, чтобы заставить сервер приложений передавать управление обратно в IIS для обслуживания файла (проверка безопасности, конечно, была бы раньше). Или, наконец, как вы указали, ваш сервер приложений может внедрить заголовки ответов, а затем httpmodule прочитает их и передаст управление IIS. Не уверен насчет java, но в .NET вы можете использовать метод HttpResponse.TransmitFile для передачи управления IIS - это должно исключить необходимость использования файла HttpModule.

Наконец, для кеширования вы всегда можете выдавать заголовки кеша в ответ на пониженный уровень (кеширование на стороне прокси или клиента). Если файлы меняются, вы можете добавить файловую зависимость и т. Д.

РЕДАКТИРОВАТЬ: Не уверен, что это будет работать для вас. Создайте обработчик http (ashx) и отметьте его как SSL, необходимый в IIS. Все медиа-файлы будут обслуживаться этим обработчиком. Обработчик примет файл, который будет служить параметром запроса. Теперь вы можете передать некоторый идентификатор файла или зашифрованный частичный путь (относительно настроенного базового пути к хранилищу файлов), чтобы фактическое имя файла или пути не были видны пользователю. Вы даже можете создавать токены, срок действия которых истекает через некоторое время (по сути, добавлять идентификатор файла и отметку времени и шифровать его), чтобы пользователь не мог снова запросить тот же файл, используя тот же параметр. Псевдокод для обработчика будет

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);
}
1 голос
/ 14 декабря 2010

Это может работать:

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

В частности, кусок x-sendfile.

...