NetworkStream.DataAvailable ne marque pas la fin d'une réponse HTTP

NetworkStream.DataAvailable == false signifie qu'aucun octet n'est prêt à être lu immédiatement. Cela ne signifie pas qu'une réponse HTTP est terminée. Une boucle qui s'arrête là peut tronquer un téléchargement SOCKS parfaitement normal pendant un intervalle entre paquets.

Une fois que SOCKS a établi la connexion TCP, le cadrage HTTP fournit toujours la règle d'achèvement :

• Un corps avec Content-Length se termine après les octets de contenu déclarés.
• Une réponse chunked exige son chunk terminal et les trailers applicables.
• Une réponse délimitée par la connexion se termine avec la connexion.
• Certains statuts et réponses à HEAD n'ont pas de corps.

Lisez le statut et les en-têtes pour déterminer la règle applicable. Attendre uniquement la fermeture n'est pas une solution générale, car une réponse HTTP complète peut laisser la connexion ouverte. La capacité d'un tampon n'a pas davantage de rapport avec la longueur de la réponse.

Utilisez l'implémentation de cadrage du client HTTP lorsqu'elle prend en charge le transport proxy choisi. Sur un runtime .NET moderne compatible, envisagez la prise en charge native de SOCKS par HttpClient. Une implémentation brute doit conserver l'état d'analyse entre les en-têtes partiels et les lectures de corps, et distinguer l'achèvement réussi de l'annulation, du délai d'attente et d'une fin de flux inattendue. Pour une demande de lecture non vide, zéro octet lu signifie que le flux est terminé ; cela diffère de l'absence d'octets en file d'attente à cet instant.

Le proxy peut rendre visibles les écarts de temporisation, mais il ne transforme pas une file de réception vide en marqueur de fin de message.