В Apache (ч/з mod_xsendfile) и в lighttpd есть такая замечательная штука
как обработка заголовка ответа X-Sendfile через sendfile(2).
Полезно, если напр. сервер отдающий большие файлы находится далеко от
fastcgi сервера. Да и даже если близко, то нет способа для fastcgi
скрипта авторизовать юзера перед передачей большого файла без
использования редиректов.
В nginx по идее есть sendfile, но только во перловом модуле (как и в
mod_perl Апача). Т.е. обработать ответ от upstream я не могу.
Было бы замечательно, если бы и подобная функциональность была бы и у
nginx.
P.S. С помощью sendfile можно реализовать много чего, напр. у меня
кешируется динамический контент (примерно так, как у Apache2
mod_disk_cache).
nginx поддерживает более общий заголовок "X-Accel-Redirect:
/download/file".
location /download/ {
internal;
root ...;
}
Из ответа бэкенда при этом наследуются заголовки:
Set-Cookie
Content-Disposition
Cache-Control
Expires
Accept-Ranges
Обнаружил только одну небольшую проблему (или фичу).
Если напр. конф. такая:
location /download.cgi {
fastcgi_pass ....
if ($request_method != "POST") {
return 405;
}
}
location /download/ {
internal;
root ...;
}
то в /download/ уже оказывается метод != POST и юзер получает 405.
А на /download.cgi GET'ом долбится бесчисленное множество качалок, хотелось бы
чтобы они отрубались достаточно просто не доходя до нагруженного fastcgi
сервера. Как можно надежно проверить в if является ли запрос internal ?
Нужно, чтобы клиент слал только POST, он уходил на FastCGI,
а тот прислылал "X-Accel-Redirect: /download/..." ?
Прилагаемый патч, превращает POST в GET для внтутреннего редиректа и,
кроме того, позволяет вместо
if ($request_method != "POST") {
писать
limit_except POST {
deny all;
}
Игорь Сысоев
