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