Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [feature request] X-Sendfile
On Monday 24 April 2006 05:37, Igor Sysoev wrote:
> On Sun, 23 Apr 2006, Sergey Serov wrote:
> > В 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 ?
|