<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">вт, 12 июл. 2022 г. в 19:51, Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.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">Hello!<br>
<br>
On Tue, Jul 12, 2022 at 04:45:45PM +0300, Gena Makhomed wrote:<br>
<br>
> On 10.07.2022 11:41, Maxim Dounin wrote:<br>
> <br>
> > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP<br>
> > request to HTTPS port".  Как и другие ошибки в клиентских<br>
> > запросах, эти ошибки логгируются на уровне info.<br>
> <br>
> nginx/1.23.0 из официального репозитория <a href="http://nginx.org" rel="noreferrer" target="_blank">nginx.org</a><br>
> <br>
> В error.log есть такая запись:<br>
> <br>
> 2022/07/12 16:00:00 [error] 16594#16594: *21415 access forbidden by <br>
> rule, client: 62.46.205.111, server: <a href="http://gitlab.example.com" rel="noreferrer" target="_blank">gitlab.example.com</a>, request: "GET <br>
> /api/v4/user HTTP/2.0", host: "<a href="http://gitlab.example.com" rel="noreferrer" target="_blank">gitlab.example.com</a>"<br>
> <br>
> То, что какому-то клиенту возвращается 403 статус - разве это ошибка,<br>
> которую необходимо писать в error.log на уровне [error] а не [info] ?<br>
> <br>
> Кстати, директивы limit_conn_log_level и limit_req_log_level<br>
> зачем-то по умолчанию стоят на уровне error, как будто это есть<br>
> ошибка на стороне сервера, если какому-то клиенту будет запрещен<br>
> доступ.<br>
> <br>
> Директива deny_log_level в nginx вообще отсутствует.<br>
<br>
Ограничения и ошибки доступа логгируются на уровне error, так как <br>
считаются важными (и, вообще говоря, не являются ошибками в</blockquote><div><br></div><div>если я в конфиге пишу deny, и применяется заданное мной правило, в чем же тут ошибка, о которой надо мне сообщить в лог ?</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>
запросов).  Как в случае access forbidden by rule в allow/deny, <br>
так и в случае user not found / password mismatch в auth_basic, а <br>
равно "directory index ... forbidden", "open() ... failed (2: <br>
No such file or directory)" и limit_conn/limit_req.<br>
<br>
Для гибкого изменения уровней логгирования (или вообще <br>
логгирования) в сложных случаях - есть некоторое количество ручек, <br>
позволяющих гибко управлять логгированием конкретных событий <br>
(limit_conn_log_level, limit_req_log_level, log_not_found, <br>
rewrite_log).  В общем случае - таких ручек нет, и события <br>
попадают в лог на фиксированном уровне логгирования.<br>
<br>
> Может быть имеет смысл сделать директиву deny_log_level<br>
> и для всех трех директив: limit_conn_log_level,<br>
> limit_req_log_level и deny_log_level сделать значением<br>
> по умолчанию info ?<br>
> <br>
> Это было бы логично и соответствовало бы общему правилу,<br>
> что все ошибки в клиентских запросах логгируются на уровне info.<br>
<br>
Менять на info - совершенно точно нет, это противоречит как логике <br>
выбора уровня логгирования ошибок (см. выше), так и логике работы, <br>
скажем, limit_req - при уровне логгирования info не остаётся <br>
разницы между фатальными ошибками и задержками запросов.<br>
<br>
Добавить возможность настройки уровня логгирования ошибок deny - <br>
возможно, но пока кажется, что это скорее не нужно.<br>
<br>
Что касается общих правил, то см. выше.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-ru mailing list -- <a href="mailto:nginx-ru@nginx.org" target="_blank">nginx-ru@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-ru-leave@nginx.org" target="_blank">nginx-ru-leave@nginx.org</a><br>
</blockquote></div></div>