Lire l'upload par morceaux n'exige pas HTTP chunked
Séparez les lectures applicatives bornées du cadrage des messages HTTP/1.1 quand un upload se comporte différemment à travers un proxy direct.
Non. Un client peut lire un gros fichier dans de petits tampons et l'envoyer avec un Content-Length connu. Les lectures bornées maîtrisent la mémoire ; le cadrage HTTP indique au destinataire où se termine le corps de la requête.
Un fichier stable dont la bibliothèque HTTP connaît la longueur en octets diffère d'un générateur produisant une quantité inconnue de données. Utilisez l'interface de corps prise en charge par la bibliothèque pour l'une ou l'autre source. Il n'est pas nécessaire d'assembler tout le fichier dans une chaîne uniquement pour fournir une longueur.
Pour HTTP/1.1, examinez le cadrage réellement envoyé : Content-Length ou codage de transfert chunked selon les règles du protocole. Le codage chunked ajoute des marqueurs de taille en dehors du contenu du fichier. Ne combinez pas des champs de cadrage contradictoires et ne devinez pas une longueur pour convaincre un proxy d'accepter l'upload.
Si un upload passant par un proxy échoue, notez la version HTTP, la source du corps et le premier refus. Une réponse 411 suggère une autre investigation qu'une connexion qui se ferme au milieu d'un corps. Si ce sont plutôt les nouvelles tentatives d'authentification qui échouent, vérifiez si le corps de l'upload peut être rejoué. Modifier la taille du tampon de lecture de l'application peut laisser le cadrage de la requête exactement tel qu'il était.
La route compte pour cette observation. Le transfert en clair expose le cadrage HTTP de l'upload au proxy ; un HTTPS ordinaire de bout en bout le place dans un tunnel. HTTP/2 utilise son propre cadrage. Les limitations historiques de Squid expliquent donc certains échecs anciens, et non une règle selon laquelle tout proxy actuel rejetterait les uploads en flux.