એક વેબસાઇટને તમારી બાકીની HTTPS વિનંતીઓ કરતાં અલગ પ્રોક્સીની જરૂર છે. Requests એ પસંદગી પ્રોક્સી શબ્દકોશમાં જ વ્યક્ત કરી શકે છે:

routes = {
    "https://reports.example": "http://reports-proxy.example:8080",
    "https": "http://default-proxy.example:8080",
}
response = requests.get(
    "https://reports.example/monthly",
    proxies=routes,
    timeout=(5, 20),
)
response.raise_for_status()

તે ગંતવ્ય માટે હોસ્ટનામ-વિશિષ્ટ કી જીતે છે. બીજું HTTPS હોસ્ટનામ સ્કીમ-વ્યાપી એન્ટ્રી વાપરે છે. મૂલ્યો પ્રોક્સી જોડાણનું વર્ણન કરે છે, તેથી HTTPS ગંતવ્ય યોગ્ય રીતે HTTP પ્રોક્સી URL સાથે મેપ થઈ શકે છે. જ્યારે આ પ્રોક્સી ખાતાં વગરની માન્ય જાહેર-સાઇટ રૂટ હોય, ત્યારે HTTP પ્રોક્સી સૂચિ તે મૂલ્યો માટે ઉમેદવારો પૂરા પાડી શકે છે; દરેક ગંતવ્ય નિયમ સ્પષ્ટ રાખો.

હોસ્ટનામ મેળવો, સ્રોત URL નહીં

Requests 2.32.5 માં વિશિષ્ટ કી ગંતવ્યની સ્કીમ અને પાર્સ કરેલા હોસ્ટનામમાંથી બને છે. તેમાં પાથ, ક્વેરી કે પોર્ટ નથી હોતા.

શબ્દકોશની કીમાં /monthly ઉમેરવાથી નિયમ તે પાથ સુધી મર્યાદિત નહીં થાય. એ જ રીતે, https://reports.example:8443 આ સિલેક્ટર ઓળખે એવી પોર્ટ-વિશિષ્ટ કી નથી. ગંતવ્ય URL બીજો પોર્ટ વાપરે ત્યારે પણ હોસ્ટનામ નિયમ લાગુ પડે છે.

આ શોધમાં કોઈ વાઇલ્ડકાર્ડ વિસ્તરણ નથી. reports.example માટેનો નિયમ સબડોમેનને આપમેળે આવરી લેતો નથી. નીતિને પાથ, પોર્ટ કે પ્રત્યય મેળવવાની જરૂર હોય ત્યારે આ સાદા શબ્દકોશની બહાર સ્પષ્ટ રાઉટિંગ નિર્ણય વાપરો.

જાણો આગળ કયો ફોલબેક આવે છે

અમલીકરણ આ ક્રમમાં કી ચકાસે છે: scheme://hostname, scheme, all://hostname, પછી all. તેથી સ્કીમ-વ્યાપી HTTPS એન્ટ્રી બધા સ્કીમના હોસ્ટનામ એન્ટ્રી પર પ્રાધાન્ય ધરાવે છે. જ્યારે તે ઇચ્છિત અપવાદ હોય, ત્યારે તમારી ડિઝાઇનમાં સ્કીમ-વિશિષ્ટ હોસ્ટનામ નિયમ પહેલા મૂકો.

તમારું Session ડિફોલ્ટ અને પર્યાવરણ-આધારિત સેટિંગ્સ કેવી રીતે જોડે છે તે પણ ધ્યાનમાં લો. આ બે સ્પષ્ટ એન્ટ્રી વિનંતી સાથે મોકલવાથી તેમના ઇચ્છિત રૂટ સ્પષ્ટ થાય છે, પણ બીજા કોઈ પણ ગંતવ્ય સ્કીમ માટે નીતિ નક્કી કરતું નથી.

રીડાયરેક્ટ બીજું હોસ્ટનામ લાવી શકે છે, અને પ્રોક્સી પસંદગી તે નવા ગંતવ્ય માટે પણ સંબંધિત છે. નિયમને પહેલા પૃષ્ઠ સાથે જોડાયેલા કાયમી રૂટ તરીકે નહીં, પણ દરેક વિનંતી કરેલ URL વિશેના નિર્ણય તરીકે વાંચો.

સંબંધિત લેખો