gzip બાઇટ્સને તેમનું વર્ણન કરતા હેડર્સ સાથે ફોરવર્ડ કરો

જો Requests એ પહેલેથી જ બોડી ડીકોમ્પ્રેસ કરી છે, તો Content-Encoding: gzip સાથે ફોરવર્ડ કરવાથી આગલા ક્લાયન્ટને તેને ફરી ડીકોમ્પ્રેસ કરવા કહેવાય છે. હેડર્સ કૉપી કરતા પહેલા નક્કી કરો કે પ્રોક્સી કયું પેલોડ રજૂઆત મોકલે છે.

એન્કોડેડ પેલોડ બાઇટ્સ માટે, આ ટુકડો 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 ભૂલો સંભાળો: આ ઉદાહરણ તેમને ફોરવર્ડ કરવાને બદલે ફેંકે છે.