ପ୍ରକ୍ସି ପଛରେ Requests ର ପ୍ରତିକ୍ରିୟା ବିକୃତ ଦେଖାଯାଉଛି? Brotli ସମର୍ଥନ ଯାଞ୍ଚ କରନ୍ତୁ
କପି କରାଯାଇଥିବା Accept-Encoding:br ହୋଷ୍ଟେଡ୍ Requests ପରିବେଶର ଡିକୋଡର ସମର୍ଥନକୁ ଅତିକ୍ରମ କରିପାରେ।
ଲାପଟପ୍ ଏବଂ ହୋଷ୍ଟେଡ୍ ପ୍ରକ୍ରିୟାକୁ ଦୁଇଟି ଭିନ୍ନ ସ୍ତରରେ ତୁଳନା କରନ୍ତୁ:
| ସ୍ତର | ପ୍ରଶ୍ନ |
|---|---|
| Content-Encoding | କ୍ଲାଏଣ୍ଟ ଫେରାଯାଇଥିବା gzip/deflate/Brotli ବାଇଟ୍ ଡିକମ୍ପ୍ରେସ୍ କରିପାରିବ କି? |
| Charset | ଡିକମ୍ପ୍ରେସ୍ ହୋଇଥିବା ବାଇଟ୍ କିପରି ପାଠ୍ୟ ହୁଏ? |
Requests ସାଧାରଣତଃ gzip/deflate ସମ୍ଭାଳେ; Brotli ପାଇଁ ସଂସ୍ଥାପିତ ସମର୍ଥିତ ଲାଇବ୍ରେରୀ ଆବଶ୍ୟକ। ହାତରେ କପି କରାଯାଇଥିବା Accept-Encoding br ଘୋଷଣା କରିପାରେ ଯେତେବେଳେ ଏହି ପରିବେଶ ଏହାକୁ ଡିକୋଡ୍ କରିପାରିବ ନାହିଁ। UTF-8 ପାଠ୍ୟ ଚୟନ Brotli ଡିକମ୍ପ୍ରେସ୍ କରେ ନାହିଁ।
ଯେତେବେଳେ ଉଦ୍ଦେଶ୍ୟପୂର୍ବକ ବୁଝାମଣା ସୀମିତ କରାଯାଏ:
response = session.get(
url,
proxies={"https": "http://proxy.example:8080"},
headers={"Accept-Encoding": "gzip, deflate"},
timeout=30,
)
response.raise_for_status()ବିଦ୍ୟମାନ Session, HTTPS URL ଏବଂ ଆବଶ୍ୟକ ହେଡର/ପ୍ରମାଣୀକରଣ ବ୍ୟବହାର କରନ୍ତୁ। ଉଭୟ ମେସିନରେ ବାହାରକୁ ଯାଉଥିବା Accept-Encoding, ଭିତରକୁ ଆସୁଥିବା Content-Encoding ଏବଂ ପ୍ୟାକେଜ ସମର୍ଥନ ତୁଳନା କରନ୍ତୁ; ରୂପାନ୍ତରକାରୀ ମଧ୍ୟସ୍ଥ ପୁରୁଣା ମେଟାଡାଟା ମଧ୍ୟ ଦେଇପାରେ। ପୃଥକ ସାର୍ବଜନୀନ ପୃଷ୍ଠା ତୁଳନା ଯେଉଁଠି ସାର୍ବଜନୀନ ମଧ୍ୟସ୍ଥ ଅନୁମତିପ୍ରାପ୍ତ ସେଠାରେ ଏହାର ପ୍ରକ୍ସି URL ପାଇଁ HTTP ପ୍ରକ୍ସି ତାଲିକା ବ୍ୟବହାର କରିପାରେ, କିନ୍ତୁ ଉତ୍ତରାଧିକାରୀ ପ୍ରକ୍ସି ପ୍ରମାଣପତ୍ର, କପି ହୋଇଥିବା ଖାତା ହେଡର କିମ୍ବା ବ୍ୟକ୍ତିଗତ ବଡି ଡାଟା ବିନା।
ଅନ୍ୟଥା ସାଧାରଣ କ୍ଲାଏଣ୍ଟ ବୁଝାମଣାକୁ ପ୍ରାଥମିକତା ଦିଅନ୍ତୁ। Requests ର ସୁବିଧାଜନକ content/text ଇଣ୍ଟରଫେସ ସମର୍ଥିତ କୋଡିଂ ଡିକୋଡ୍ କରେ, ତେଣୁ ହେଡର ଏହାର ନାମ ନେଇଛି କେବଳ ସେହି କାରଣରୁ ସେମାନଙ୍କ ଆଉଟପୁଟ୍ ପୁନର୍ବାର ଡିକମ୍ପ୍ରେସ୍ କରନ୍ତୁ ନାହିଁ।