ngx_http_bytes_filter_module & Content-Range

[Aleksej Novikov]

Hello Maxim,


Спасибо за живое участие!


Клиент: стандартный. 

Задача:
Имеется файл (к примеру 100мб длиной). Данные внутри файла актуализируются постепенно (файл пишется многопоточным доунлоудером).

Клиент не знает о текущем состоянии файла и количестве потоков, которое используется для его записи.

Требуется правильно скорректировать возврат данных при обращении к файлу через http. 
То есть. Клиент запрашивает 4 потока по 25мб каждый. К примеру 1 и 3 потоки началами диапазонов удачно попали в уже имеющиеся данные, но концы диапазонов находятся в еще неготовой области. Тогда сервер должен вернуть header что он отдает не запрошенный диапазон, а только ту часть, которая уже готова на сервере (к примеру Content-Range: bytes 0-999/104857600, при этом в реальности пользователь запрашивал Range: bytes=0-26214400).

В текущей реализации предполагается, что первоначальный запрос от клиента принимается скриптом на сервере, который по известной ему схеме определяет, попал ли пользователь в существующий диапазон и какая именно часть диапазона уже готова для отдачи. Далее скрипт должен инициализоровать выдачу существующего диапазона данных клиенту с учетом корректировок в заголовках, которые были описаны выше.




Wednesday, May 27, 2009, 6:12:49 PM, you wrote:

> Hello!

> On Tue, May 26, 2009 at 08:20:49PM +0300, Aleksej Novikov wrote:

>> Hello Maxim,

>> Monday, May 25, 2009, 6:31:18 PM, you wrote:

>> > Hello!

>> > On Mon, May 25, 2009 at 06:00:11PM +0300, Aleksej Novikov wrote:

>> >>    Hello Nginx-ru,
>> >> 
>> >>      Возникла необходимость в специфической отдаче файлов с
>> >>    использованием  Range запросов.
>> >> 
>> >>    Был обнаружен замечательный патч написанный Maxim Dounin под названием
>> >>    ngx_http_bytes_filter_module

>> > Это не патч, это модуль.

>> Пардон !


>> >>    И всё бы замечательно но столкнулся с проблемой. Когда я с помощью
>> >>    этого модуля запрашиваю например отдать мне первые 100 байтов с 0 по 99
>> >>    от файла размером 100 килобайт
>> >> 
>> >>    то nginx выдаёт в ответе свой собственный заголовок  Content-Range:
>> >>    bytes 0-99/100  (с какого по какой запросил, и суммарный размер)
>> >> 
>> >>    А хотелось бы получить вместо этого  Content-Range: bytes 0-1/100000 -
>> >>    то есть чтобы указывался полный размер файла, а не возвращаемый объём.
>> >> 
>> >>    Попытка погасить данный Header c использованием fastch_hide_header
>> >>    ничего не дала - заголовок явно ставиться после работы модуля (в
>> >>    internal location)
>> >> 
>> >>    Может кто-то может порекомендовать решение длля возникшей проблемы ?

>> > Выкинуть ngx_http_bytes_filter_module - он вам не нужен.  
>> > Используйте просто range-запросы.

>> > Модуль ngx_http_bytes_filter_module нужен в том случае, если 
>> > требуется получить кусок файла в виде отдельного документа.

>> Дело  в  том,  что  определение  того, какой range мне нужен (а точнее
>> необходимо  отдать  клиенту)  определяется в момент запроса к серверу.
>> Запрос   попадает   на   php  скрипт,  который  определяет  (получает)
>> необходимый  range  и  делает X-Accel-Redirect на internal location  в
>> котором используется ngx_http_bytes_filter_module и  происходит отдача
>> указанного range. Отсюда и вырастает эта проблема.

> RFC 2616 в разделе 10.2.7 206 Partial Content говорит нам, что 
> если Range в запросе не было - то его возвращать нельзя.  А если в 
> запросе он был - то непонятно зачем нужен бекенд и что именно он 
> определяет.

>> Был  бы признателен, Максим, если бы Вы подсказали как решить подобное
>> без Вашего модуля.

> Вы для начала сформулируйте на простом человеческом языке в чём 
> состоит задача.  Не "бекенд определяет ...", а хотя бы "клиент 
> приходит с запросом ... и должен получить в ответ ...".

> Ну и определитесь заодно - клиент стандартный HTTP, или как сами 
> напишете так и будет.

> Maxim Dounin




-- 
Best regards,
Aleksej             
ICQ:    293-686-24
GSM:371-293-686-24
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090529/f35e9d4d/attachment.html>