gzip বাইটগুলোকে সেগুলোর বর্ণনা দেয় এমন হেডারসহ পাঠান
Requests-ভিত্তিক প্রক্সিতে এনকোডেড বা ডিকোডেড পেলোড বেছে নিন, তারপর ডাউনস্ট্রিম প্রতিক্রিয়াকে মিলিয়ে content হেডার ও নিজস্ব ফ্রেমিং দিন।
যদি Requests ইতিমধ্যে একটি বডি ডিকম্প্রেস করেছে, তবে Content-Encoding: gzip সহ তা পাঠালে পরবর্তী ক্লায়েন্টকে এটি আবার ডিকম্প্রেস করতে বলা হয়। হেডার কপি করার আগে প্রক্সি কোন পেলোড উপস্থাপনা পাঠাবে তা নির্ধারণ করুন।
| পাঠানো পেলোড | content হেডার |
|---|---|
| মূল এনকোডেড বাইট | প্রযোজ্য কোডিং এবং সঠিক পেলোড দৈর্ঘ্য রাখুন |
| ডিকোডেড বাইট | ডিকোডেড কোডিং সরান; সংশ্লিষ্ট দৈর্ঘ্য সরান বা পুনরায় গণনা করুন |
এনকোডেড পেলোড বাইটের জন্য, এই অংশটি urllib3-এর কাঁচা স্ট্রিম content ডিকোডিং ছাড়াই পড়ে:
with requests.get(url, stream=True, timeout=(5, 30)) as upstream:
upstream.raise_for_status()
for block in upstream.raw.stream(65536, decode_content=False):
downstream.write(block)downstream হলো বিদ্যমান প্রতিক্রিয়া আউটপুট। এর স্ট্যাটাস ও হেডার ইতিমধ্যে নির্বাচিত নীতি অনুসরণ করবে; এই অংশটি সম্পূর্ণ প্রক্সি সার্ভার বাস্তবায়ন করে না।
ট্রান্সফার ফ্রেমিং gzip content কোডিং থেকে আলাদা। আপস্ট্রিম HTTP লাইব্রেরি ইতিমধ্যে ফ্রেমিং সামলেছে, চাঙ্ক অপসারণসহ, তাই Transfer-Encoding অন্ধভাবে কপি করবেন না। ডাউনস্ট্রিম সার্ভার নিজের প্রতিক্রিয়া ফ্রেম করে এমনকি যখন পেলোড gzip-এনকোডেড থাকে।
response.text এর পরে UTF-8 এনকোডিং করলেও উপস্থাপনা বদলে যায় এবং ইচ্ছামতো বাইনারি ডেটা সংরক্ষণ করতে পারে না। প্রতিটি পথে আপস্ট্রিম প্রতিক্রিয়া বন্ধ করুন বা ব্যবহার করুন, এবং প্রক্সি চুক্তি অনুযায়ী HTTP ত্রুটি সামলান: এই উদাহরণ সেগুলো পাঠানোর বদলে উত্থাপন করে।