[error] access forbidden by rule

[Илья Шипицин]

вт, 12 июл. 2022 г. в 19:51, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Tue, Jul 12, 2022 at 04:45:45PM +0300, Gena Makhomed wrote:
>
> > On 10.07.2022 11:41, Maxim Dounin wrote:
> >
> > > Вы чуть раньше в этом треде писали Илье, "client sent plain HTTP
> > > request to HTTPS port".  Как и другие ошибки в клиентских
> > > запросах, эти ошибки логгируются на уровне info.
> >
> > nginx/1.23.0 из официального репозитория nginx.org
> >
> > В error.log есть такая запись:
> >
> > 2022/07/12 16:00:00 [error] 16594#16594: *21415 access forbidden by
> > rule, client: 62.46.205.111, server: gitlab.example.com, request: "GET
> > /api/v4/user HTTP/2.0", host: "gitlab.example.com"
> >
> > То, что какому-то клиенту возвращается 403 статус - разве это ошибка,
> > которую необходимо писать в error.log на уровне [error] а не [info] ?
> >
> > Кстати, директивы limit_conn_log_level и limit_req_log_level
> > зачем-то по умолчанию стоят на уровне error, как будто это есть
> > ошибка на стороне сервера, если какому-то клиенту будет запрещен
> > доступ.
> >
> > Директива deny_log_level в nginx вообще отсутствует.
>
> Ограничения и ошибки доступа логгируются на уровне error, так как
> считаются важными (и, вообще говоря, не являются ошибками в


если я в конфиге пишу deny, и применяется заданное мной правило, в чем же
тут ошибка, о которой надо мне сообщить в лог ?


>
> клиентских запросах, а являются ошибками обработки клиентских
> запросов).  Как в случае access forbidden by rule в allow/deny,
> так и в случае user not found / password mismatch в auth_basic, а
> равно "directory index ... forbidden", "open() ... failed (2:
> No such file or directory)" и limit_conn/limit_req.
>
> Для гибкого изменения уровней логгирования (или вообще
> логгирования) в сложных случаях - есть некоторое количество ручек,
> позволяющих гибко управлять логгированием конкретных событий
> (limit_conn_log_level, limit_req_log_level, log_not_found,
> rewrite_log).  В общем случае - таких ручек нет, и события
> попадают в лог на фиксированном уровне логгирования.
>
> > Может быть имеет смысл сделать директиву deny_log_level
> > и для всех трех директив: limit_conn_log_level,
> > limit_req_log_level и deny_log_level сделать значением
> > по умолчанию info ?
> >
> > Это было бы логично и соответствовало бы общему правилу,
> > что все ошибки в клиентских запросах логгируются на уровне info.
>
> Менять на info - совершенно точно нет, это противоречит как логике
> выбора уровня логгирования ошибок (см. выше), так и логике работы,
> скажем, limit_req - при уровне логгирования info не остаётся
> разницы между фатальными ошибками и задержками запросов.
>
> Добавить возможность настройки уровня логгирования ошибок deny -
> возможно, но пока кажется, что это скорее не нужно.
>
> Что касается общих правил, то см. выше.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list -- nginx-ru на nginx.org
> To unsubscribe send an email to nginx-ru-leave на nginx.org
>
----------- следующая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20220712/47bdb91f/attachment.htm>