Une progression lente peut maintenir un téléchargement via proxy dans son délai de lecture

Une réponse qui livre quelques octets de temps en temps peut rester dans chaque limite d'inactivité de lecture tout en prenant beaucoup trop de temps au total. Un délai de lecture n'a pas à mesurer toute la durée du transfert.

Choisissez la politique selon la charge de travail. Une archive finie a besoin d'un budget d'achèvement ; un flux d'événements peut légitimement durer des heures et rester silencieux par moments.

Mesurer la progression utile

Pour un téléchargement de fichier, conservez une échéance globale et envisagez les contrôles de faible vitesse ou de progression pris en charge par le client. Définissez l'intervalle et la quantité de données utiles. Un octet de battement de cœur peut montrer de l'activité sans progresser réellement vers l'achèvement du fichier.

Gardez la configuration du tunnel séparée du transfert du corps. Attendre la fin de CONNECT et recevoir un corps de destination lent sont des étapes différentes avec des preuves différentes.

Consommez ou fermez la réponse sur chaque chemin de sortie. Laisser un flux lent ouvert peut faire attendre la requête suivante pour la capacité du pool, ce qui produit un autre délai d'expiration pour une raison différente.

Si la durée observée dépasse la politique prévue, inspectez la version exacte du client et la boucle de lecture. Un minuteur d'inactivité correct, le comportement d'une boucle personnalisée et un bogue d'implémentation demandent chacun un correctif différent.