Żądanie WinHTTP uwierzytelnia się na serwerze proxy, otrzymuje 401 od witryny, a następnie przy kolejnym wysłaniu dostaje jeszcze jedno 407. Serwer proxy i witryna mają odrębne stany uwierzytelniania, a ścieżka ponownego wysłania musi zachować oba.

Przykład natywnego uwierzytelniania WinHTTP firmy Microsoft przechowuje wybrany schemat serwera proxy w zmiennej i ponownie stosuje konto proxy przed każdym WinHttpSendRequest po wybraniu tego schematu.

  1. Wyślij żądanie i sprawdź odpowiedź.
  2. W przypadku 407 zapytaj o oferowane schematy i zapamiętaj wybrany schemat serwera proxy.
  3. Przed ponownym wysłaniem wywołaj WinHttpSetCredentials dla WINHTTP_AUTH_TARGET_PROXY z tym schematem i kontem.
  4. W przypadku 401 od miejsca docelowego pobierz jego schemat i ustaw jego poświadczenia serwera, zachowując zapamiętany stan serwera proxy na następne wysłanie.

Przykład wyraźnie wskazuje ponowne uwierzytelnienie po wyzwaniu serwera lub przekierowaniu jako powód ponownego zastosowania poświadczeń serwera proxy. Umieszczenie wywołania tylko w pierwszej gałęzi 407 może pozostawić inną ścieżkę ponowienia bez oczekiwanej konfiguracji.

Sprawdzaj każdy wynik API i ograniczaj powtarzające się błędy. Zwięzły przykład firmy Microsoft śledzi poprzedni stan, a produkcyjna polityka ponowień powinna także rozpoznawać powtarzającą się sekwencję naprzemienną.

Jeśli po błędzie użytkownik poda konto zastępcze, zaktualizuj wartości używane przez tę ścieżkę ponownego wysłania. WinHttpSetCredentials działa w zakresie żądania; nie jest procesowym magazynem haseł, którego zawartość byłaby zastępowana dla wszystkich przyszłych żądań.

Powiązane artykuły