Запазване на буферираните данни след отговор на HTTP CONNECT
Избегнете заседнало ръкостискане на HTTP CONNECT, като намерите границата на заглавките в отговора и запазите байтовете след нея.
Малка прокси обвивка може да работи за HTTPS и после да увисне, когато се използва отново за протокол, в който сървърът говори пръв. Подозрителният ред често е този, който чака приемащият буфер да завършва с \r\n\r\n.
TCP дава на клиента поток. Едно извикване за приемане може да върне половин ред за състояние на HTTP, пълен отговор CONNECT или този отговор, последван веднага от данни на тунела. Няма обещание, че четенето ще спре в края на заглавките.
Намерете границата в буфера
При обмен на HTTP/1.1 CONNECT натрупвайте байтове, докато терминаторът на заглавките се появи навсякъде в буфера. Разделете при първото му срещане. Разберете реда за състояние и заглавките от първата част; запазете всичко след границата отделно. Прилагайте ограничение за размера на заглавките и изчакване, докато чакате, а празно четене от сокета третирайте като затворена връзка, не като ново покана за цикъл.
Крайният успешен отговор 2xx превключва връзката в режим на тунел веднага след тези заглавки. Следващите му байтове вече са байтове на тунела. Не ги изхвърляйте, не чакайте тяло на отговор CONNECT и не тълкувайте поле Content-Length като разрешение да изразходвате част от новия протокол. Информационните отговори, ако ги има, трябва да се обработят преди крайния отговор.
Обвивката трябва да предаде остатъка си
Връщането само на базовия сокет губи всички байтове, които анализаторът на ръкостискането вече е изтеглил от него. Следващият читател се нуждае от буфериран поток, който първо връща запазената опашка и после подновява четенето от сокета. При протокол, в който сървърът говори пръв, загубата на това първоначално поздравително съобщение може да остави двете страни да чакат безкрайно.
Обратно, байтовете от неуспешен отговор CONNECT не са поздравително съобщение на тунел. 407 все още принадлежи на прокси обмена и изисква обработка на удостоверяването; друг неуспешен статус изисква подходящ път за грешка.
Това е особено важно при адаптиране на FTP или SSH клиент през HTTP прокси. Проксито също трябва да разрешава заявения порт на местоназначението, а FTP може да се нуждае от допълнителни връзки за данни. Правилният разбор на заглавките решава предаването на потока; той не може да даде разрешение CONNECT или да осигури втория канал на FTP.