Thanks Maxim!

I didn't really pay attention to the difference in the error messages.
Thanks for remembering them.

The question of the severity of the last message has no simple answer I'm
afraid, since it depends on the use case.
Maybe someone wishes to log any attempt to access a protected ressource ?
Not sending credential is then considered as an 'error'
Maybe someone only consider a 'void' attempt as an error if it's not the
1st access in a short time. The problem I see here is there is that HTTP
having no memory (stateless), there is no way has knowing such thing as
'1st access' or not.
More than that, I think that's user-centric definition, not really an
'error' as such.

The main problem here is that this message is generated when the
credentials are asked for, which is a normal flow of a use-case scenario
for a standard protected resource.
Filtering for errors against a specific resources will then generated loads
of unmeaningful entries, potentially hiding interesting ones.

1°) Since cancelling sending credentials when requested generates 403,
there must be a way for Nginx to differentiate 1st connection attempt to
the followings: can't that be used to avoid logging an error message on 1st
attempt (and log it in access log instead)? Downgrading this message
severity for this case.
2°) As an extra feature, is there a way for Nginx to remember (at cost of
memory) access attempts on (conf defined) short time, logging errors only
if a trigger made of (conf defined) multiple attempts is reached?
---
*B. R.*
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx