Requests-ის პასუხი პროქსის მიღმა გაფუჭებულად გამოიყურება? შეამოწმეთ Brotli-ის მხარდაჭერა

კოპირებული Accept-Encoding:br შეიძლება გაუსწროს ჰოსტინგურ Requests გარემოს დეკოდერის მხარდაჭერას.

შეადარეთ ლეპტოპი და ჰოსტინგური პროცესი ორ სხვადასხვა დონეზე:

დონეკითხვა
Content-Encodingშეუძლია კლიენტს დაბრუნებული gzip/deflate/Brotli ბაიტების გაშლა?
Charsetროგორ იქცევა გაშლილი ბაიტები ტექსტად?

Requests ჩვეულებრივ ამუშავებს gzip/deflate-ს; Brotli მოითხოვს დაინსტალირებულ მხარდაჭერილ ბიბლიოთეკას. ხელით კოპირებულმა Accept-Encoding-მა შეიძლება გამოაცხადოს br, მაშინ როცა ეს გარემო ვერ დეკოდირებს მას. UTF-8 ტექსტის არჩევა Brotli-ს არ ხსნის.

როცა მოლაპარაკება განზრახ შემოიფარგლება:

response = session.get(
    url,
    proxies={"https": "http://proxy.example:8080"},
    headers={"Accept-Encoding": "gzip, deflate"},
    timeout=30,
)
response.raise_for_status()

გამოიყენეთ არსებული Session, HTTPS URL და საჭირო სათაურები/ავთენტიფიკაცია. შეადარეთ გამავალი Accept-Encoding, შემავალი Content-Encoding და პაკეტების მხარდაჭერა ორივე მანქანაზე; გარდამქმნელ შუამავალს ასევე შეუძლია მოძველებული მეტამონაცემების მიწოდება. ცალკე საჯარო გვერდის შედარება შეიძლება იყენებდეს HTTP პროქსების სია-ს თავისი პროქსის URL-ისთვის იქ, სადაც საჯარო შუამავლები დაშვებულია, მემკვიდრეობით მიღებული პროქსის სერთიფიკატების, კოპირებული ანგარიშის სათაურების ან პირადი სხეულის მონაცემების გარეშე.

სხვა შემთხვევაში უპირატესობა მიეცით კლიენტის ჩვეულებრივ მოლაპარაკებას. Requests-ის მოხერხებული content/text ინტერფეისები დეკოდირებენ მხარდაჭერილ კოდირებას, ამიტომ ნუ გახსნით მათ გამოსავალს ხელახლა მხოლოდ იმიტომ, რომ სათაური მას ასახელებს.

დაკავშირებული სტატიები