પ્રોક્સી પાછળ 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 અને પેકેજ સપોર્ટ સરખાવો; રૂપાંતર કરતું મધ્યસ્થ પણ જૂનું મેટાડેટા આપી શકે છે. અલગ જાહેર પૃષ્ઠ સરખામણી HTTP પ્રોક્સી સૂચિ નો ઉપયોગ તેના પ્રોક્સી URL માટે કરી શકે છે જ્યાં જાહેર મધ્યસ્થોને મંજૂરી હોય, પરંતુ વારસાગત પ્રોક્સી ઓળખપત્રો, કોપી કરેલા એકાઉન્ટ હેડરો કે ખાનગી બોડી ડેટા વગર.
અન્યથા સામાન્ય ક્લાયન્ટ વાટાઘાટને પ્રાધાન્ય આપો. Requests ના અનુકૂળ content/text ઇન્ટરફેસ સપોર્ટેડ કોડિંગ ડિકોડ કરે છે, તેથી હેડર તેનું નામ લે છે એ ફક્ત કારણે તેનું આઉટપુટ ફરી ડિકોમ્પ્રેસ ન કરો.