Membaca muat naik dalam ketulan tidak memerlukan HTTP chunked
Asingkan bacaan aplikasi yang terbatas daripada pembingkaian mesej HTTP/1.1 apabila muat naik berkelakuan berbeza melalui proksi hadapan.
Tidak. Klien boleh membaca fail besar dalam penimbal kecil dan menghantarnya dengan Content-Length yang diketahui. Bacaan terbatas mengawal penggunaan memori; pembingkaian HTTP memberitahu penerima di mana badan permintaan berakhir.
Fail stabil yang panjang baitnya diketahui pustaka HTTP berbeza daripada penjana yang menghasilkan jumlah data tidak diketahui. Gunakan antara muka badan yang disokong pustaka untuk kedua-dua sumber. Anda tidak perlu mencantum keseluruhan fail menjadi rentetan hanya untuk memberikan panjang.
Untuk HTTP/1.1, periksa pembingkaian yang benar-benar dihantar: Content-Length atau pengekodan pemindahan chunked mengikut peraturan protokol. Pengekodan chunked menambah penanda saiz di luar kandungan fail. Jangan gabungkan medan pembingkaian yang bercanggah dan jangan meneka panjang untuk memujuk proksi menerima muat naik.
Jika muat naik melalui proksi gagal, catat versi HTTP, sumber badan dan penolakan pertama. Respons 411 mencadangkan penyiasatan berbeza daripada sambungan yang ditutup di tengah badan. Jika sebaliknya percubaan semula pengesahan gagal, semak sama ada badan muat naik boleh dimainkan semula. Menukar saiz penimbal baca aplikasi mungkin membiarkan pembingkaian permintaan tetap seperti asalnya.
Laluan penting untuk pemerhatian itu. Penghantaran teks biasa mendedahkan pembingkaian HTTP muat naik kepada proksi; HTTPS hujung-ke-hujung biasa meletakkannya di dalam terowong. HTTP/2 menggunakan pembingkaiannya sendiri. Oleh itu had Squid sejarah menerangkan kegagalan lama tertentu, bukan peraturan bahawa setiap proksi semasa menolak muat naik penstriman.