Den Upload in Blöcken zu lesen erfordert kein chunked HTTP
Trennen Sie begrenzte Anwendungslesevorgänge von der HTTP/1.1-Nachrichtenrahmenstruktur, wenn sich ein Upload über einen Forward-Proxy anders verhält.
Nein. Ein Client kann eine große Datei in kleinen Puffern lesen und mit einer bekannten Content-Length senden. Begrenzte Lesevorgänge steuern den Speicherverbrauch; die HTTP-Rahmenstruktur teilt dem Empfänger mit, wo der Anfragetext endet.
Eine stabile Datei, deren Bytelänge die HTTP-Bibliothek kennt, unterscheidet sich von einem Generator, der eine unbekannte Datenmenge erzeugt. Verwenden Sie für beide Quellen die von der Bibliothek unterstützte Body-Schnittstelle. Sie müssen nicht die gesamte Datei in einen String packen, nur um eine Länge anzugeben.
Untersuchen Sie bei HTTP/1.1 die tatsächlich gesendete Rahmenstruktur: Content-Length oder chunked Transferkodierung nach den Regeln des Protokolls. Chunked-Kodierung fügt Größenmarker außerhalb des Dateiinhalts hinzu. Kombinieren Sie keine widersprüchlichen Rahmenfelder und raten Sie keine Länge, um einen Proxy zur Annahme des Uploads zu bewegen.
Wenn ein Upload über einen Proxy fehlschlägt, notieren Sie HTTP-Version, Body-Quelle und die erste Ablehnung. Eine 411-Antwort deutet auf eine andere Untersuchung hin als eine Verbindung, die mitten im Body schließt. Scheitern stattdessen Authentifizierungswiederholungen, prüfen Sie, ob der Upload-Body erneut abgespielt werden kann. Eine Änderung der Lesepuffergröße der Anwendung kann die Anfrage-Rahmenstruktur genau so belassen, wie sie war.
Die Route ist für diese Beobachtung wichtig. Klartext-Weiterleitung legt die HTTP-Rahmenstruktur des Uploads gegenüber dem Proxy offen; gewöhnliches End-to-End-HTTPS legt sie in einen Tunnel. HTTP/2 verwendet seine eigene Rahmenstruktur. Historische Squid-Einschränkungen erklären daher bestimmte alte Fehlschläge, nicht die Regel, dass jeder heutige Proxy gestreamte Uploads ablehnt.