Апрацоўнікі CONNECT у Node.js павінны захоўваць буфер head
Працуйце з сокетам CONNECT і буферам head у Node на мяжы паміж 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, якія трэба адкінуць.