Qu'est-ce qui cause une erreur 400 Bad Request pour null («») et pourquoi nos journaux nginx en auraient-ils autant?

Les journaux quotidiens de Logwatch signalent régulièrement 400 demandes incorrectes, nulles: 1744 heure (s) à partir de nos journaux nginx.

Les entrées du journal ressemblent à ceci:

123.123.123.123 - - [25/Jan/2011:14:44:19 -0500] "-" 400 173 "-" "-"

Quelqu'un peut-il expliquer comment ceux-ci sont générés et pourquoi il y en a tellement? Cela ne semble pas faire de mal, mais nous en avons eu jusqu'à 8 000 en une journée. Nous hébergeons une application de rails de taille moyenne fonctionnant sur licorne et nginx.

Il y a une discussion dans le forum nginx, mais je n'ai pas trouvé de vraie solution qui diminue le nombre de 400 Bad Reqeusts enregistrés.

— johnml
source

Quelles sont les adresses IP qui font les mauvaises requêtes? Comme il est dit dans le fil, il peut s'agir d'un programme de surveillance qui ouvre uniquement une connexion TCP.

— Mark Wagner

Il existe de nombreuses adresses IP. La plupart ont une session qui inclut du trafic Web normal mélangé à ces 400. Je pense que je n'ai été témoin de l'activité des navigateurs IE que dans des exemples où je me suis concentré sur la valeur du trafic d'une session.

— johnml

J'ai remarqué sur mon serveur que l'utilisation de Firefox pour accéder à une page donne toujours l'un de ces 400 journaux vides exactement 5 secondes après la dernière demande valide, tandis que Firebug ne montre aucune erreur. Cela donne du crédit à la réponse de @ Avleen.

— Phrogz

Cela se produit souvent lorsqu'un navigateur utilise Keep-Alive et atteint le délai d'expiration Keep Alive. C'est tout à fait normal.

Si vous voyez 400 erreurs avec un URI / chemin / méthode tel que GET ou POST, etc., alors vous avez un problème légitime avec un utilisateur faisant une mauvaise demande. Mais cela devrait être rare.

— Avleen
source