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