Node.js CONNECT руковаоци морају сачувати head бафер
Управљајте Node CONNECT сокетом и head бафером на граници HTTP-а и тунела, чувајући бајтове који су већ прочитани после заглавља.
Node HTTP сервер обрађује обичан proxy захтев кроз свој callback за захтев. CONNECT иде другим путем: сервер емитује connect са захтевом, клијентским сокетом и head бафером.
Тај догађај је примопредаја између HTTP парсирања и тунела. Не постоји обичан ServerResponse објекат који би се могао наставити користити за тунелирани саобраћај.
| Аргумент | Шта носи |
|---|---|
req | CONNECT захтев, укључујући одредишни ауторитет и заглавља |
clientSocket | Веза назад према клијенту |
head | Тунелски подаци које је Node већ прочитао након HTTP заглавља, могуће празни |
Завршите HTTP одлуку пре прослеђивања бајтова
Проверите тражени host и port, примените политику приступа и аутентификације proxy-а и успоставите везу према узводном серверу. CONNECT идентификује ауторитет попут service.example:443; парсирајте тај облик имајући на уму IPv6 ауторитете, уместо да слепо делите на свакој двотачки.
Када се тунел прихвати, пошаљите успешан HTTP одговор праћен његовим завршним празним редом. Затим проследите све head бајтове узводно пре него што наставите са каснијим бајтовима из клијентског сокета. Прикључивање новог data listener-а не може повратити бафер који је већ засебно достављен руковаоцу.
Node-ов званични пример тунелирања обавља ту примопредају са serverSocket.write(head) пре повезивања два смера тока. Његов мали пример илуструје транзицију; имплементирани proxy такође захтева ограничене покушаје повезивања, контроле приступа и управљање животним циклусом.
Након успеха, бајтови припадају протоколу услуге
Успешан CONNECT одговор претвара везу у ток бајтова. Ако је циљ HTTPS веб-локација, њена TLS размена путује унутар тог тока. Само тунелирање не захтева да proxy изда заменски сертификат веб-локације.
Пре прихватања CONNECT, HTTP грешка може објаснити зашто је одбијен. Након прихватања, уписивање HTTP 500 у ток би убацило бајтове у тунелирани протокол. Уместо тога, прекините или уништите одговарајуће везе при каснијим неуспесима.
Повежите оба смера са руковање током свесно повратног притиска, и одлучите како end, error и close догађаји прекидају партнера. Сачувајте почетни head бафер као део истог модела власништва; то су апликацијски подаци, а не вишак HTTP заглавља за одбацивање.