Дайджэст-аўтэнтыфікацыя проксі ў Requests
Адрознівайце дайджэст-аўтэнтыфікацыю прызначэння ў Requests ад дайджэст-аўтэнтыфікацыі проксі і патрабаванняў да яго HTTPS-тунэля.
HTTPDigestAuth у Requests апрацоўвае аўтэнтыфікацыю прызначэння. Проксі ж вяртае статус 407 з Proxy-Authenticate і патрабуе ўласнай апрацоўкі аўтэнтыфікацыі.
requests-toolbelt прадастаўляе HTTPProxyDigestAuth для апрацоўкі запытаў проксі і падрыхтоўкі аўтарызацыі проксі. Праверце сумяшчальнасць з дакладнымі версіямі Requests і транспартнага слоя, якія выкарыстоўваюцца.
HTTPS CONNECT патрабуе асобнай падтрымкі
Проксі можа выстаўляць запыт падчас усталявання тунэля CONNECT, перш чым звычайны адказ прызначэння дасягне апрацоўнікаў адказу. Таму апрацоўка бачнага 407 не даказвае падтрымку ўсіх шляхоў аўтэнтыфікацыі CONNECT.
Для HTTPS-цэляў выкарыстоўвайце кліент або падтрымліваную інтэграцыю, якая яўна падтрымлівае патрэбную аўтэнтыфікацыю проксі на этапе ўсталявання тунэля. Monkey patch-ы, прывязаныя да састарэлых унутранасцей Requests або urllib3, патрабуюць падтрымліванай заявы аб сумяшчальнасці перад паўторным выкарыстаннем.
Запісвайце патрабаванні да аўтэнтыфікацыі проксі і прызначэння ў асобных палях, уключаючы этап, на якім узнікла памылка. Гэта паказвае, які запыт апрацаваны, а які яшчэ патрабуе падтрымкі.