പ്രോക്സിക്ക് പിന്നിൽ 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 ഇന്റർഫേസുകൾ പിന്തുണയുള്ള കോഡിംഗ് ഡീകോഡ് ചെയ്യുന്നു, അതിനാൽ ഹെഡർ അതിന്റെ പേര് പറയുന്നത് കൊണ്ട് മാത്രം അവയുടെ ഔട്ട്പുട്ട് വീണ്ടും ഡീകംപ്രസ് ചെയ്യരുത്.