HTTP/1.0 206 Partial Content + Content-Range: bytes

[AleXXX V. NovikoFF]

Fri, 10 Mar 2006 19:14:35 +0300 (MSK)
Igor Sysoev <is at rambler-co.ru> писал(а):

> On Thu, 9 Mar 2006, AleXXX V. NovikoFF wrote:
> 
> > Mon, 6 Mar 2006 22:44:55 +0300 (MSK)
> > Igor Sysoev <is at rambler-co.ru> писал(а):
> >
> >> On Tue, 7 Mar 2006, AleXXX V. NovikoFF wrote:
> >>
> >>> Можно ли от бэкэнда передать ответ фронтэнду типа такого:
> >>>
> >>> header('X-AccelRedirect: /path/to/internal/file');
> >>> header('Content-Range: bytes 0-10239/10240');
> >>> header('Content-Length:10240');
> >>>
> >>> Т.е. моя задача - ограничить объем отдаваемый фронтэндом юзеру, чтобы он
> >>> не забрал больше 10 кб например, в идеале бы было еще лучше, если бы
> >>> можно было отдать ТОЛЬКО header('Content-Length:10240'); и nginx бы уже
> >>> сам отдал не более 10 кб клиенту (в независимости от запрошенного
> >>> фрагмента). Планируется ли что-нибудь в этом духе? Это было бы удобно
> >>> при создании сервисов с оплатой за трафик (собственно что я и
> >>> разрабатываю на основе вашего сервера)
> >>
> >> Такой функциональности нет. В принципе, можно сделать что-нибудь
> >> вроде "X-Accel-Limit: 10240", по которому просто обрывать ответ после
> >> 10K. Выдавать 206 не стоит, возможно, браузерам такой ответ не понравится,
> >> если они спецально не запросили range.
> >
> > а что-то аналогичное, только по времени лимит? реально?
> > что-нить типа X-Accel-Timeout: 3600
> > а то делаю kill -HUP и воркеры висят еще по 10-20 часов... в итоге их
> > накапливается очень много (HUP раз  час) в итоге все начинает жутко
> > тормозить...
> 
> kill -TERM старые процессы.

тогда просто все коннекты порвутся, не сработает post_action, сессии
останутся открытыми и трафик на засчитается...

-- 
AleXXX V. NovikoFF <alexxx at alexxx.ru>