Gérer l'EOF dans une boucle de lecture SOCKS en Python
Gérez explicitement l'EOF dans une boucle de lecture exacte SOCKS au lieu de traiter une connexion fermée comme un délai d'attente qui n'arrive jamais.
Une boucle veut huit octets d'une réponse SOCKS. Elle en a reçu trois. La lecture suivante renvoie b'', la boucle l'ajoute, vérifie la longueur et réessaie indéfiniment.
C'est un bug de gestion de l'EOF, pas un proxy lent qui aurait besoin d'un délai plus long. Pour une réception normale sur une socket de flux, une chaîne d'octets vide signifie que le pair s'est déconnecté. Les cinq octets restants n'arriveront pas sur cette connexion.
Un assistant de lecture exacte a besoin de trois issues distinctes : accumuler des fragments non vides, échouer sur EOF avant la longueur requise et propager un délai d'attente ou une autre erreur de socket. Ces cas ne doivent pas se fondre dans une unique boucle de nouvelle tentative générique.
Réglez le délai d'attente prévu de la socket avant l'opération et lisez les longueurs de champ spécifiées par le protocole du proxy. Une seule réception ne peut renvoyer qu'une partie d'une réponse. À l'inverse, demander un grand tampon fixe ne fait pas que chaque adresse SOCKS ait cette longueur.
Ne réparez pas une dépendance en collant un ancien extrait MSG_WAITALL dans sa source et en supposant qu'il couvre EOF, les signaux et le comportement de la plateforme. Préférez le correctif pris en charge de l'implémentation maintenue, ou implémentez délibérément le contrat de l'assistant lorsque l'analyseur est votre code.
Conservez le nombre d'octets attendus et reçus, sans journaliser les charges utiles d'identifiants. « EOF après trois des huit octets de réponse » explique bien mieux l'échange cassé que « le proxy a encore figé ».