Η ανάγνωση του upload σε τμήματα δεν απαιτεί chunked HTTP

Όχι. Ένας client μπορεί να διαβάσει ένα μεγάλο αρχείο σε μικρά buffers και να το στείλει με γνωστό Content-Length. Οι φραγμένες αναγνώσεις ελέγχουν τη χρήση μνήμης· η μορφοποίηση HTTP λέει στον παραλήπτη πού τελειώνει το σώμα του αιτήματος.

Ένα σταθερό αρχείο του οποίου το μήκος σε bytes γνωρίζει η βιβλιοθήκη HTTP διαφέρει από μια γεννήτρια που παράγει άγνωστη ποσότητα δεδομένων. Χρησιμοποιήστε τη διεπαφή σώματος που υποστηρίζει η βιβλιοθήκη και για τις δύο πηγές. Δεν χρειάζεται να συναρμολογήσετε ολόκληρο το αρχείο σε string μόνο για να δώσετε μήκος.

Για HTTP/1.1, εξετάστε τη μορφοποίηση που στάλθηκε πραγματικά: Content-Length ή chunked transfer coding σύμφωνα με τους κανόνες του πρωτοκόλλου. Η chunked κωδικοποίηση προσθέτει δείκτες μεγέθους έξω από το περιεχόμενο του αρχείου. Μη συνδυάζετε αντιφατικά πεδία μορφοποίησης και μην μαντεύετε μήκος για να πείσετε ένα proxy να δεχτεί το upload.

Αν ένα upload μέσω proxy αποτύχει, καταγράψτε την έκδοση HTTP, την πηγή του σώματος και την πρώτη απόρριψη. Μια απάντηση 411 υποδεικνύει διαφορετική έρευνα από μια σύνδεση που κλείνει στη μέση ενός σώματος. Αν αντίθετα αποτυγχάνουν οι επαναλήψεις ταυτοποίησης, ελέγξτε αν το σώμα του upload μπορεί να αναπαραχθεί. Η αλλαγή του μεγέθους του read-buffer της εφαρμογής μπορεί να αφήσει τη μορφοποίηση του αιτήματος ακριβώς όπως ήταν.

Η διαδρομή έχει σημασία για αυτή την παρατήρηση. Η προώθηση απλού κειμένου εκθέτει τη μορφοποίηση HTTP του upload στο proxy· το συνηθισμένο end-to-end HTTPS τη βάζει μέσα σε σήραγγα. Το HTTP/2 χρησιμοποιεί τη δική του μορφοποίηση. Έτσι, οι ιστορικοί περιορισμοί του Squid εξηγούν συγκεκριμένες παλιές αποτυχίες, όχι έναν κανόνα ότι κάθε σημερινό proxy απορρίπτει streamed uploads.