যদি 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 ত্রুটি সামলান: এই উদাহরণ সেগুলো পাঠানোর বদলে উত্থাপন করে।

সম্পর্কিত নিবন্ধ