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 სათაურები.