د 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 تېروتنې د پراکسي تړون سره سم سمبال کړئ: دا بېلګه هغوی غورځوي پرځای لدې چې مخې ته یې ولېږي.

اړوندې مقالې