Erreurs BADREQ haproxy

Un preconnect à partir d'un navigateur peut également entraîner un BADREQ si le navigateur n'utilise pas toutes les connexions. Par exemple, lorsque l'utilisateur ne télécharge qu'un seul fichier par navigateur.

Cela signifie qu'il y a deux causes possibles de BADREQ avec du cR-- ou du CR-- (vérifié avec HAProxy v1.5-dev24) :

1. Connexion inutilisée : Cela signifie que pour HTTP(S), un client s'est connecté via TCP mais aucun en-tête de requête HTTP n'a été envoyé jusqu'au timeout http-request (CR--) ou que le client a refermé la connexion (cR--). Cause : Connexion inutilisée à partir d'un preconnect d'un client normal ou d'un équilibreur de charge ou à partir d'un scan.
2. Mauvaise requête. Un client a envoyé une mauvaise requête. Ces erreurs devraient être visibles via la socket de statistiques (voir réponse précédente de womble).

La plupart des navigateurs modernes comme Firefox ou Chrome font un préconnect. J'ai remarqué que Firefox ou Chrome ouvraient toujours au moins 2 connexions même si le navigateur n'effectue qu'une seule requête comme le téléchargement d'un fichier (par exemple, uniquement le téléchargement de http://cdn.sstatic.net/serverfault/img/favicon.ico).

Augmenter la valeur de timeout http-request dans votre configuration HAProxy peut aider à réduire ces entrées de journal pour les connexions inutilisées car une valeur plus élevée signifie plus de chances que la connexion sera utilisée par un client, mais vous risquez également que votre serveur ne puisse plus gérer toutes les connexions ouvertes (inactives). Si vous utilisez un autre équilibreur de charge comme Amazon ELB devant HAProxy, vérifiez que ce délai dans HAProxy correspond à celui de l'équilibreur de charge, car ils pourraient également utiliser le preconnect.

Pour les connexions inutilisées, vous pouvez utiliser option dontlognull dans HAProxy pour désactiver ces entrées de journal. Citation de la documentation de HAProxy pour cette option :

Il est généralement recommandé de ne pas utiliser cette option dans des environnements non contrôlés (par exemple sur Internet), sinon les scans et autres activités malveillantes ne seraient pas enregistrés.

=> Le client n'a jamais terminé sa demande, qui a été interrompue par le
   délai d'attente ("c---") après 5s, alors que le proxy attendait les en-têtes
   de la demande ("-R--"). Rien n'a été envoyé à aucun serveur, mais le proxy aurait pu
   renvoyer un code 408 au client.

Solution : changez "timeout http-request" en 20s ou plus au lieu de 5s.

Juste une journée perdue sur ce problème. Nous avons découvert que certains en-têtes de requête étaient trop volumineux. 8k est la taille maximale par défaut dans HAProxy (tous les en-têtes combinés) et notre entreprise adore les cookies. Dans notre cas, environ 8% des en-têtes de requête étaient trop volumineux et ont donc été tronqués après le 8092ème octet.

À partir de la documentation :

Si la requête HTTP est plus grande que (tune.bufsize - tune.maxrewrite), haproxy renverra une erreur HTTP 400 (Mauvaise Requête). De même, si une réponse HTTP est plus grande que cette taille, haproxy renverra une erreur HTTP 502 (Passerelle Incorrecte).

Nous avons mis à jour le fichier haproxy.cfg avec les valeurs suivantes :

global
  # la limite de la requête est (bufsize - maxrewrite), notre limite souhaitée est de 16k (8k est la valeur par défaut)
  tune.maxrewrite  16384
  tune.bufsize     32768

J'espère que cela vous aidera !

BADREQ signifie simplement que le client a envoyé une mauvaise requête ; en mode HTTP, cela pourrait signifier que le client a fait une erreur, et il n'y a rien que vous puissiez faire à ce sujet. Pour voir quelle était précisément l'erreur, connectez-vous au socket des statistiques (en utilisant socat) et exécutez show errors. Il y a de fortes chances que ce soit quelqu'un qui essaie d'exécuter une attaque sur un autre serveur web, vous pouvez donc l'ignorer.