Pertahankan Data yang Terbuffer Setelah Balasan HTTP CONNECT
Hindari handshake HTTP CONNECT yang macet dengan menemukan batas header balasan dan mempertahankan byte yang datang setelahnya.
Pembungkus proxy kecil dapat bekerja untuk HTTPS lalu macet saat dipakai ulang untuk protokol yang servernya berbicara lebih dulu. Baris yang mencurigakan sering kali adalah baris yang menunggu buffer penerimaan berakhir dengan \r\n\r\n.
TCP memberi klien sebuah aliran. Satu panggilan penerimaan bisa mengembalikan separuh baris status HTTP, balasan CONNECT yang lengkap, atau balasan itu yang langsung diikuti data terowongan. Tidak ada jaminan bahwa pembacaan berhenti di akhir header.
Temukan batas di dalam buffer
Untuk pertukaran HTTP/1.1 CONNECT, kumpulkan byte sampai penanda akhir header muncul di mana pun dalam buffer. Pisahkan pada kemunculan pertamanya. Uraikan baris status dan header dari bagian pertama; simpan semua yang setelah batas secara terpisah. Terapkan batas ukuran header dan batas waktu selama menunggu, dan perlakukan pembacaan socket kosong sebagai koneksi tertutup, bukan ajakan lain untuk mengulang.
Balasan 2xx terakhir yang berhasil mengalihkan koneksi ke mode terowongan tepat setelah header tersebut. Byte yang menyusulnya sudah merupakan byte terowongan. Jangan membuangnya, jangan menunggu badan balasan CONNECT, dan jangan menafsirkan bidang Content-Length sebagai izin untuk mengonsumsi sebagian protokol baru. Balasan informasional, jika ada, harus ditangani sebelum balasan terakhir itu.
Pembungkus harus meneruskan sisa-sisanya
Mengembalikan hanya socket yang mendasarinya menghilangkan byte apa pun yang sudah ditarik parser handshake darinya. Pembaca berikutnya memerlukan aliran terbuffer yang lebih dulu memberikan ekor tersimpan lalu melanjutkan pembacaan socket. Untuk protokol yang servernya berbicara lebih dulu, kehilangan sapaan awal itu dapat membuat kedua pihak menunggu tanpa batas.
Sebaliknya, byte dari balasan CONNECT yang gagal bukanlah sapaan terowongan. 407 tetap milik pertukaran proxy dan memerlukan penanganan autentikasi; status tidak berhasil lainnya memerlukan jalur kesalahan yang sesuai.
Hal ini terutama penting saat mengadaptasi klien FTP atau SSH melalui proxy HTTP. Proxy juga harus mengizinkan port tujuan yang diminta, dan FTP mungkin memerlukan koneksi data tambahan. Penguraian header yang benar menyelesaikan penyerahan aliran; ia tidak dapat memberikan izin CONNECT atau menyediakan kanal kedua FTP.