Re: upload module и @fallback

Valery Kholodkov valery+nginx на grid.net.ru
Пт Дек 16 19:25:38 UTC 2011


Давным давно в 2006 году проходил патч, который это решал. Теперь я даже не помню, был ли это UWCGI или wsCGI, но суть в том, что он сливал последовательность буферов в один.

-- 
Best regards,
Valery Kholodkov

On 16 Dec 2011, at 19:38, Roman Vasilyev <roman.vasilyev на yousendit.com> wrote:

> Пытаюсь отработать случай когда UWSGI процесс сдох, что бы не терять данные которые на этот момент уже были успешно залиты, подразумевается $request_body записать в fallback.log и потом их оттуда вынуть скриптом.
> есть следующая конфигурация:
> location /upload {
>      upload_resumable on;
>      upload_pass      /uwsgi/upload.py;
> .........
> }
> 
> location ~ /uwsgi/(?P<app>(.*))\.py$ {
>    error_page 502 504 = @fallback;
>    root html/uwsgi;
> 
>    uwsgi_pass   127.0.0.1:9001;
>    include      uwsgi_params;
> .........
> }
>  location @fallback {
>    default_type text/plain;
>    return 200 '$request_body';
>  }
> 
> прибиваю процесс uwsgi, если шлю POST на /uwsgi/upload.py то вижу ожидаемы результат
> ===========================================
> ------WebKitFormBoundarySrDJ2gn2ydy6aS68
> Content-Disposition: form-data; name="file"; filename="test.py"
> Content-Type: text/x-python
> 
> test data
> 
> ------WebKitFormBoundarySrDJ2gn2ydy6aS68--
> ===========================================
> 
> если же то же самое шлю на /upload то получаю некий обрубок исходных данных насколько я понимаю, вместо ожидаемого потока который поидее был отправлен на вход uwsgi процессу
> ===========================================
> ------WebKitFormBoundaryX7PyvqpoxiZwQxfr
> Content-Disposition: form-data; name="
> ===========================================
> 
> Вопрос, где моя ошибка если таковая имеется, если нет то как выходить из ситуации?



Подробная информация о списке рассылки nginx-ru