Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > Где-то тут общение с бекендом завершено, однако ответ ещё не > полностью отправлен клиенту. В процессе отправки клиенте > закрывает HTTP/2 stream: Кстати да, я немного не досмотрел. В этом server {} не используется listen http2. Но, в логах наблюдается именно http/2.0 и в хроме видно h2 в консоли разработчика. Не могли бы вы подсказать, насколько это адекватно?
> При этом в функции ngx_http_terminate_request(), которая обновляет > статус запроса тогда и только тогда, когда статус либо ещё не > стоит, либо клиенту вообще ничего не было отправлено. В данном > случае, видимо, за счёт использования HTTP/2 случается ситуация, > когда клиенту вообще ничего не отправлено (вероятно, за счёт > других данных в соединении), и статус таки обновляется на 499. > > Ситуация с $upstream_status "-", видимо, получается похожим > образом: если в процессе работы с бекендом клиент отменяет HTTP/2 > stream, то у соответствующей этому stream'у структуре соединения > будет проставлен флаг c->error. И если после этого случается > timeout бекенда, то в ngx_http_upstream_next() nginx, увидев > стоящий флаг c->error, не пойдёт на следующий бекенд, а вместо > этого завершит обработку запроса с кодом 499. > > То есть я был неправ, получить в логах 499 при использовании > proxy_ignore_client_abort таки можно, хотя и непросто. В простых > случаях это в основном затрагивает HTTP/2, но и в HTTP/1.x можно > получить похожее поведение, например, при использовании > подзапросов. > > На практике при использовании proxy_ignore_client_abort это > означает, что работа с бекендом завершена или не начиналась. > > Возвращаясь к исходному вопросу: да, текущее поведение выглядит > нормально. Постараюсь описать ситуацию. Мы пытаемся выгружать эти логи в clickhouse для анализа latency и работы бекендов в целом, и сбора разнообразной статистики. Для этого на выходе у нас ожидается, что переменные (после парсинга это массивы в нашем случае) $upstream_addr, $upstream_response_time и $upstream_status имеют одну длину. Но, как показала практика, это не всегда так. В связи с этим ещё один, вероятно последний, вопрос. Есть ли возможность сделать это поведение более предсказуемым? Или проще добавлять недостающие элементы массива в процессе обработки (по сути угадывая, что там должно быть)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286718#msg-286718 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru