gzip ባይቶችን ከሚገልጹት ራስጌዎች ጋር አስተላልፍ

በRequests ላይ የተመሠረተ ፕሮክሲ ውስጥ የተመሰጠረ ወይም የተፈታ payload ይምረጡ፣ ከዚያ የታችኛው ምላሽ ተገቢውን content headers እና የራሱን framing ይስጡ።

Requests አንድ አካልን አስቀድሞ ከፈተ ከሆነ፣ በContent-Encoding: gzip ማስተላለፍ ቀጣዩ ደንበኛ እንደገና እንዲከፍተው ይጠይቃል። ራስጌዎቹን ከመቅዳት በፊት ፕሮክሲው የትኛውን የpayload ውክልና እንደሚልክ ይወስኑ።

የተላከ payloadየcontent ራስጌዎች
የመጀመሪያው የተመሰጠረ ባይትተገቢውን coding እና ትክክለኛውን የpayload ርዝመት ይያዙ
የተፈታ ባይትየተፈታውን coding ያስወግዱ፤ ተጓዳኙን ርዝመት ያስወግዱ ወይም እንደገና ያሰሉ

ለተመሰጠሩ payload ባይቶች፣ ይህ ክፍል የurllib3 ጥሬ ዥረትን ያለ content decoding ያነባል፡

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 ነባሩ የምላሽ ውጤት ነው። ሁኔታውና ራስጌዎቹ አስቀድመው የተመረጠውን ፖሊሲ መከተል አለባቸው፤ ይህ ክፍል ሙሉ ፕሮክሲ አገልጋይ አይተገበርም።

የማስተላለፊያ framing ከgzip content coding የተለየ ነው። የላይኛው HTTP ቤተ-መጽሐፍት ቀድሞውኑ framing ን አስተናግዷል፣ chunk ማስወገድን ጨምሮ፣ ስለዚህ Transfer-Encoding ን በዓይነ ስውር አይቅዱ። የታችኛው አገልጋይ payload በgzip ተመስጥሮ ቢቀርም የራሱን ምላሽ ያዘጋጃል።

response.text ከUTF-8 encoding ጋር መጠቀሙም ውክልናውን ይለውጣል፤ የዘፈቀደ ሁለትዮሽ ውሂብን ማስቀመጥ አይችልም። በሁሉም መንገድ የላይኛውን ምላሽ ይዝጉ ወይም ይጠቀሙበት፣ እና የHTTP ስህተቶችን በፕሮክሲ ውል መሠረት ያስተናግዱ፡ ይህ ምሳሌ ከማስተላለፍ ይልቅ ይጥላቸዋል።

ተዛማጅ ጽሑፎች