Erreurs BADREQ haproxy

Un Preconnect d'un navigateur pourrait également conduire à BADREQ si le navigateur n'utilise pas toutes les connexions. Par exemple, lorsqu'un utilisateur télécharge uniquement un fichier par navigateur.

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

1. Connexion inutilisée : Cela signifie que, pour HTTP(S), un client s'est connecté par TCP mais aucun en-tête de requête HTTP n'a été envoyé jusqu'à timeout http-request (CR--) ou que le client a refermé la connexion à nouveau (cR--). Cause : Connexion inutilisée à partir d'un préconnect d'un client normal ou d'un équilibreur de charge ou d'une analyse.
2. Mauvaise requête. Un client a envoyé une mauvaise requête. Ces erreurs devraient être visibles via la prise de statistiques (voir la 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, en téléchargeant uniquement http://cdn.sstatic.net/serverfault/img/favicon.ico)

Augmenter la valeur de timeout http-request dans votre configuration HAProxy peut aider à réduire de telles entrées de journal pour les connexions inutilisées simplement parce qu'une valeur plus élevée signifie une plus grande chance 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 un préconnect.

Pour les connexions inutilisées, vous pouvez utiliser option dontlognull dans HAProxy pour désactiver ces entrées de journal. Citation de la documentation 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 : internet), sinon les analyses et autres activités malveillantes ne seraient pas journalisées.

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

Solution : modifier "timeout http-request" à 20s ou plus au lieu de vos 5s.

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

D'après la documentation :

Si la requête HTTP est plus grande que (tune.bufsize - tune.maxrewrite), HAProxy renverra une erreur HTTP 400 (Bad Request). De même si une réponse HTTP est plus grande que cette taille, HAProxy renverra une erreur HTTP 502 (Bad Gateway).

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

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

En espérant 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 s'est trompé, et il n'y a rien que vous puissiez faire à ce sujet. Pour voir quelle était l'erreur exacte, connectez-vous au socket de statistiques (en utilisant socat) et exécutez show errors. Il y a de fortes chances que ce soit quelqu'un qui tente d'exécuter une exploit sur un autre serveur web, vous pouvez donc l'ignorer.