<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 6 окт. 2020 г. в 15:45, Evgeniy Berdnikov <<a href="mailto:bgx@protva.ru">bgx@protva.ru</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Oct 06, 2020 at 03:21:14PM +0500, Илья Шипицин wrote:<br>
>       Наличие лимита на размер временного файла это что, повод обрывать<br>
>      закачку?<br>
> <br>
>    вы отдаете проксируемый контент по мере чтения.<br>
>    статус 200 вы отдаете практически сразу.<br>
>    поэтому клиент видит 200.<br>
>    потом вы начинаете вычитывать ответ, и постепенно отдавать клиенту.<br>
>    это регулируется (на выбор)<br>
>    proxy_buffering (по умолчанию включено)<br>
>    X-Accel-Buffering (можно отдать с апстрима)<br>
>    proxy_max_temp_file_size (по  умолчанию 1Гб)<br>
>    если вы с апстрима вычитываете на wire speed, а отдаете в узную дырочку,<br>
>    то все шансы, что ответ попытается сбуферизоваться.<br>
>    и это у него получится вплоть до размера 1Гб<br>
>    а дальше - вы уже отдали (в сторону клиента) 200. поменять уже не можете.<br>
<br>
 А с чего бы статус менять? Не влез ответ в буфер -- положили на это болт<br>
 (можно удалить файл из буфера, etc) и продолжаем отдавать клиенту дальше.<br>
<br>
>    это дефолтные настройки. их не меняют с целью сохранения совместимости<br>
>    (вдруг кто-то от них зависит).<br>
>    предполагается ответственный подход. если вы несчастливы с дефолтными<br>
>    настройками - читаете документацию, меняете на нужные.<br>
<br>
 Не знаю, как ведёт себя nginx в данной конкретной ситуации, но думаю,<br></blockquote><div><br></div><div>это определенный этап, который проходит каждый крупный сервис, который отдает файлы больше чем 1Гб :)</div><div>осознание, что дефолтные настройки не очень удачные в этом месте<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 что его авторы не столь тупы, чтобы не понимать: на апстриме всегда может<br>
 найтись файл, который в буфер не влезет. При любых значениях настроечных<br>
 параметров. Это нормальная ситуация, причём если Content-Length с апстрима<br></blockquote><div><br></div><div>с одной стороны я с вами соглашусь, что дефолтное поведение не выглядит отличным. <br></div><div>вероятно, если файл больше нельзя сохранять в кеш, то можно просто не пытаться его сохранять,</div><div>а обойтись тем, что сохранено, остаток дочитать, ну или подождать</div><div><br></div><div>с другой стороны, вы несчастны с дефолтным поведением - ок, меняете настройку на более комфортную вам <br></div><div>и живете с ней. <br></div><div><br></div><div><br></div><div>аргументы за "поменять жизнь вообще всем" тяжело заходят. но почему бы не поменять ее конкретно тому,</div><div>кто несчастен с дефолтом<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 пришёл, она опознаётся сразу. Поэтому обрыв передачи файла клиенту<br>
 в таких условиях это баг, однозначно.<br>
-- <br>
 Eugene Berdnikov<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></blockquote></div></div>