HTTP CONNECT პასუხის შემდეგ ბუფერში არსებული მონაცემების შენახვა
თავიდან აიცილეთ გაჭედილი HTTP CONNECT ხელის ჩამორთმევა პასუხის სათაურების საზღვრის მოძიებით და მის შემდეგ მოსული ბაიტების შენახვით.
პატარა პროქსი-გარსაცმი შეიძლება მუშაობდეს HTTPS-ისთვის და შემდეგ ჩაიხშოს, როდესაც ხელახლა გამოიყენება იმ პროტოკოლისთვის, რომლის სერვერიც პირველი საუბრობს. საეჭვო ხაზი ხშირად ის არის, რომელიც ელოდება მიღების ბუფერის \r\n\r\n-ით დასრულებას.
TCP კლიენტს ნაკადს აძლევს. მიღების ერთმა გამოძახებამ შეიძლება დააბრუნოს HTTP სტატუსის ხაზის ნახევარი, სრული CONNECT პასუხი, ან ეს პასუხი დაუყოვნებლივ მომდევნო გვირაბის მონაცემებით. არ არსებობს გარანტია, რომ კითხვა სათაურების ბოლოს შეჩერდება.
იპოვეთ საზღვარი ბუფერის შიგნით
HTTP/1.1 CONNECT გაცვლისთვის დააგროვეთ ბაიტები მანამ, სანამ სათაურების დასამთავრებელი ნიშანი ბუფერის ნებისმიერ ადგილას არ გამოჩნდება. გაყავით მისი პირველი გამოჩენის ადგილზე. გააანალიზეთ სტატუსის ხაზი და სათაურები პირველი ნაწილიდან; საზღვრის შემდეგ ყველაფერი ცალკე შეინახეთ. ლოდინის დროს გამოიყენეთ სათაურების ზომის ზღვარი და დროის შეზღუდვა, ხოლო ცარიელი სოკეტის კითხვა ჩაკეტილ კავშირად მიიჩნიეთ და არა ციკლის გაგრძელების ახალ მოწვევად.
საბოლოო წარმატებული 2xx პასუხი კავშირს გვირაბის რეჟიმში გადაიყვანს ამ სათაურების დაუყოვნებლივ შემდეგ. მის მომდევნო ბაიტები უკვე გვირაბის ბაიტებია. არ გადააგდოთ ისინი, არ დაელოდოთ CONNECT პასუხის სხეულს და არ განმარტოთ Content-Length ველი ახალი პროტოკოლის ნაწილის მოხმარების ნებად. ინფორმაციული პასუხები, თუ არსებობს, უნდა დამუშავდეს ამ საბოლოო პასუხამდე.
გარსაცმმა თავისი ნარჩენები უნდა გადასცეს
მხოლოდ ქვედა სოკეტის დაბრუნება კარგავს იმ ბაიტებს, რომლებიც ხელის ჩამორთმევის ანალიზატორმა უკვე ამოიღო მისგან. მომდევნო მკითხველს სჭირდება ბუფერიზებული ნაკადი, რომელიც პირველ რიგში გასცემს შენახულ კუდს და შემდეგ განაახლებს სოკეტიდან კითხვას. სერვერ-პირველი პროტოკოლისთვის ამ საწყისი მისალმების დაკარგვამ შეიძლება ორივე მხარე უსასრულოდ ლოდინში დატოვოს.
პირიქით, წარუმატებელი CONNECT პასუხის ბაიტები გვირაბის მისალმება არ არის. 407 კვლავ პროქსის გაცვლას ეკუთვნის და ავთენტიფიკაციის დამუშავებას მოითხოვს; სხვა წარუმატებელ სტატუსს შესაბამისი შეცდომის გზა სჭირდება.
ეს განსაკუთრებით მნიშვნელოვანია HTTP პროქსის მეშვეობით FTP ან SSH კლიენტის ადაპტირებისას. პროქსიმ ასევე უნდა დაუშვას მოთხოვნილი დანიშნულების პორტი, და FTP-ს შესაძლოა დამატებითი მონაცემთა კავშირები დასჭირდეს. სათაურების სწორი ანალიზი წყვეტს ნაკადის გადაცემას; მას არ შეუძლია CONNECT ნებართვის მიცემა ან FTP-ის მეორე არხის მოწოდება.