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 [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
