<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">Thanks Maxim!<br><br>I didn't really pay attention to the difference in the error messages. Thanks for remembering them.<br><br>The question of the severity of the last message has no simple answer I'm afraid, since it depends on the use case.<br>

Maybe someone wishes to log any attempt to access a protected ressource ? Not sending credential is then considered as an 'error'<br>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.<br>

More than that, I think that's user-centric definition, not really an 'error' as such.<br><br>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.<br>

Filtering for errors against a specific resources will then generated loads of unmeaningful entries, potentially hiding interesting ones.<br><br>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.<br>

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?<br></div>

<div class="gmail_extra"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font>
</div></div>