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 ದೋಷಗಳನ್ನು ನಿರ್ವಹಿಸಿ: ಈ ಉದಾಹರಣೆ ಅವುಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಬದಲು ಎಸೆಯುತ್ತದೆ.