HTTP 407 ohne verwertbare Proxy-Authenticate-Aufforderung

Ein Client kann einen Authentifizierungsmechanismus nicht allein anhand einer Statusnummer auswählen. Die Antwort des Proxys muss beschreiben, was er akzeptiert.

HTTP verlangt, dass ein Proxy, der 407 erzeugt, eine Proxy-Authenticate-Aufforderung sendet. Für einen Basic-Dienst lautet ein einfaches Beispiel:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="Office proxy"

Der numerische Status, der Headername und die schemaspezifische Syntax sind gleichermaßen wichtig. Eine gebrandete Fehlerseite mit dem Wort authentication im Text ersetzt den Header nicht. Eigene Implementierungen müssen außerdem eine vollständige HTTP-407-Antwort senden, einschließlich des Header-Abschlusses und der Body-Rahmung.

Untersuchen Sie die Antwort, die diesen Client erreicht hat

Erfassen Sie die Status- und Aufforderungsfelder, nachdem geheime Werte entfernt wurden. Ein Zwischenglied kann die Antwort verändert haben, oder ein eigener Proxy kann eine ungültige Aufforderung erzeugt haben. Vergleichen Sie diese Belege mit dem Transaktionsprotokoll des Proxys selbst.

Wenn der Dienst stattdessen 405 oder einen anderen Fehler sendet, dürfen Sie nicht jede solche Antwort in einem eigenen Client als 407 umetikettieren. Sie würden echte Verstöße gegen die Methodenrichtlinie verbergen und hätten weiterhin keine verlässliche Schema-Aushandlung. Beheben Sie das Verhalten des Dienstes oder nutzen Sie seinen dokumentierten unterstützten Authentifizierungsweg.

Mehrere Aufforderungen erfordern außerdem einen echten HTTP-Parser. Ein Komma kann Parameter oder Aufforderungen trennen; das blinde Aufteilen des gesamten Headers an Kommas kann ein Realm in Anführungszeichen beschädigen. Nutzen Sie die unterstützte Authentifizierungsimplementierung des Clients statt einer Abfolge von Zeichenkettenersetzungen.

Erst wenn die Aufforderung verwertbar ist, ist es sinnvoll zu untersuchen, warum der Credential-Anbieter kein Konto zurückgegeben hat.