Python HTTP პროქსის POST სხეულები შეიძლება rfile-ში დაბუფერდეს
წაიკითხეთ Python HTTP პროქსის მოთხოვნა ჰენდლერის დაბუფერებული შეყვანის გავლით, ნაცვლად იმ ბაიტების მოლოდინისა, რომლებმაც უკვე დატოვეს socket-ის ბუფერი.
გადამისამართებადი პროქსი კითხულობს მოთხოვნის ხაზსა და სათაურებს, გადასცემს მათ, შემდეგ კი select-ში POST სხეულს ელოდება. კლიენტმა უკვე გაგზავნა ის. ორივე მხარე ერთმანეთს ელოდება.
Python-ის BaseHTTPRequestHandler-ით სათაურების კითხვა გადის rfile-ზე, დაბუფერებულ შემავალ ნაკადზე. ამ ნაკადს შეუძლია წინ წაიკითხოს და დაიჭიროს სხეულის კუთვნილი ბაიტები. ქვედა socket-ზე ლოდინი მხოლოდ იკითხავს, მზადაა თუ არა მისი ფაილის დესკრიპტორი; არ იკითხავს, უკვე შეიცავს თუ არა Python-ის ნაკადი გამოსაყენებელ მონაცემებს.
მიჰყევით ბუფერს, რომელმაც სათაურები წაიკითხა
სხეულიც წაიკითხეთ self.rfile-ის გავლით. ნუ გადახვალთ self.connection.recv-ზე მას შემდეგ, რაც სათაურები დაბუფერებული ნაკადით გააანალიზეთ. წინააღმდეგ შემთხვევაში კოდმა შეიძლება გვერდი აუაროს ამ ნაკადის მიერ უკვე დაჭერილ ბაიტებს და დაელოდოს მონაცემებს, რომლებიც აღარასოდეს გაიგზავნება.
თავად rfile-ის select-ზე გადაცემა არ აიძულებს select-ს შეამოწმოს მისი Python ბუფერი. მზადყოფნის API მუშაობს ობიექტის ფაილის დესკრიპტორის გავლით.
მოთხოვნისთვის ერთი ვალიდური Content-Length-ით და Transfer-Encoding-ის გარეშე მოიხმარეთ ზუსტად გამოცხადებული ბაიტების რაოდენობა, მართეთ შეყვანის ნაადრევი დასასრული და თქვენი ზომისა და დროის ლიმიტები. ნუ წაიკითხავთ EOF-მდე: მუდმივი კავშირის მქონე კლიენტმა შეიძლება კავშირი ღიად დატოვოს მოთხოვნის დასრულების შემდეგ.
ჩარჩოება პროქსის ცხად ნაწილად აქციეთ
დაყოფილი მოთხოვნის სხეულებს სჭირდებათ დაყოფილი ჩარჩოების მხარდაჭერა. მათი წაკითხვა შეუძლებელია არარსებული Content-Length-ის ძებნით. ორაზროვან სიგრძის მეტამონაცემებს სჭირდება განსაზღვრული უარის გზა, ნაცვლად მოხერხებული სათაურის არჩევისა.
ბლოკირებად ჰენდლერს შეუძლია გააგრძელოს თავისი ნაკადის ინტერფეისის გამოყენება შეზღუდული კითხვებით. მოვლენებით მართულ პროქსის სჭირდება ბუფერის მოდელი, რომელიც აერთიანებს პარსერის წინასწარ კითხვას მზადყოფნის დამუშავებასთან. დროის ლიმიტის შეცვლა არ შეურიგებს ერთი და იმავე socket-ის ორ დამოუკიდებელ მომხმარებელს.
ეს დიაგნოზი ეხება იმას, სად ინახება შემავალი ბაიტები. მას შემდეგ, რაც პროქსიმ სწორი სხეული მოიხმარა, მან მაინც უნდა გადასცეს ის თანმიმდევრული HTTP ჩარჩოებით. სტანდარტული http.server ჰენდლერი სასარგებლო ადგილია მექანიზმის გასაგებად, მაგრამ ეს არ არის წარმოების გადამისამართებადი პროქსის იმპლემენტაცია.