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 վերնագրեր։