Kekalkan Data Berbuffer Selepas Balasan HTTP CONNECT
Elakkan handshake HTTP CONNECT tersekat dengan mencari sempadan pengepala balasan dan mengekalkan bait yang tiba selepasnya.
Pembalut proksi kecil boleh berfungsi untuk HTTPS dan kemudian tergantung apabila digunakan semula untuk protokol yang pelayannya bercakap dahulu. Baris yang mencurigakan selalunya ialah baris yang menunggu penimbal penerimaan tamat dengan \r\n\r\n.
TCP memberikan klien satu strim. Satu panggilan penerimaan mungkin memulangkan separuh baris status HTTP, balasan CONNECT yang lengkap, atau balasan itu diikuti serta-merta dengan data terowong. Tiada jaminan bahawa bacaan berhenti di hujung pengepala.
Cari sempadan di dalam penimbal
Untuk pertukaran HTTP/1.1 CONNECT, kumpulkan bait sehingga penamat pengepala muncul di mana-mana dalam penimbal. Pisahkan pada kemunculan pertamanya. Huraikan baris status dan pengepala daripada bahagian pertama; simpan semua selepas sempadan secara berasingan. Gunakan had saiz pengepala dan had masa semasa menunggu, dan anggap bacaan soket kosong sebagai sambungan tertutup dan bukan jemputan lain untuk bergelung.
Balasan 2xx terakhir yang berjaya menukar sambungan ke mod terowong serta-merta selepas pengepala itu. Bait yang menyusul sudah pun bait terowong. Jangan buangkannya, jangan tunggu badan balasan CONNECT, dan jangan tafsirkan medan Content-Length sebagai kebenaran untuk menggunakan sebahagian protokol baharu. Balasan bermaklumat, jika ada, mesti dikendalikan sebelum balasan terakhir itu.
Pembalut mesti menyerahkan bakinya
Memulangkan hanya soket asas akan kehilangan bait yang telah pun ditarik keluar oleh penghurai handshake. Pembaca seterusnya memerlukan strim berbuffer yang memberikan ekor tersimpan dahulu dan kemudian menyambung bacaan soket. Untuk protokol pelayan-dahulu, kehilangan sapaan awal itu boleh membiarkan kedua-dua pihak menunggu tanpa henti.
Sebaliknya, bait daripada balasan CONNECT yang gagal bukanlah sapaan terowong. 407 masih tergolong dalam pertukaran proksi dan memerlukan pengendalian pengesahan; status tidak berjaya yang lain memerlukan laluan ralat yang sesuai.
Ini amat penting apabila menyesuaikan klien FTP atau SSH melalui proksi HTTP. Proksi juga mesti membenarkan port destinasi yang diminta, dan FTP mungkin memerlukan sambungan data tambahan. Penghuraian pengepala yang betul menyelesaikan penyerahan strim; ia tidak boleh memberikan kebenaran CONNECT atau menyediakan saluran kedua FTP.