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 ਗਲਤੀਆਂ ਸੰਭਾਲੋ: ਇਹ ਉਦਾਹਰਨ ਉਹਨਾਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਦੀ ਬਜਾਏ ਸੁੱਟਦੀ ਹੈ।