Aloha ;)

Das ist auch irgendwie nachvollziehbar, nur: Welches Ziel hätte man damit erreicht? Welchen Zweck hätte die Auth-Aufforderung, wenn sie nicht erfüllbar ist? Dann kann ich doch das Auth-Gedöns auch gleich lassen - oder übersehen ich den eigentlichen Trick?

Die Antwort ist einfach. Ich kann dem User über die Seite, die mit dem 401-Header gesendet wird, eine Authentifizierungsmöglichkeit zukommen lassen - z.B. per Eingabemaske für Username und Passwort für den systemeigenen, z.b. PHP-/Session-basierten Login-Prozess, der sich ja durchaus von BASIC-AUTH unterscheiden kann, und trotzdem einen bedeutungsvollen HTTP-Statuscode senden - der z.B. Suchmaschinen davon abhält, die Loginmaske zu indizieren oder noch anderweitigen Zwecken dienen kann.

Das macht ein Browser dann wie? Wenn 401 kommt, will der Browser den nächsten Request auf eine bestimmte Art und Weise absetzen. Nun magst du den einen oder anderen *deiner* Browser wegen Open Source so anpassen können, dass er die Eingaben aus einem HTML-Formular in die richtigen Felder des Requests setzt, aber wie sollen das andere Benutzer deiner hypothetischen Seite tun? Die kriegen doch allesamt 'nen 403-er.

Ich glaube du (Martin auch?) verstehst mich vollkommen falsch. Nein, er soll nicht die Eingaben aus dem HTML-Formular in den Request setzen. Das HTML-Formular wird per Post mit den Anmeldedaten an PHP geschickt, dieses setzt bei richtiger Eingabe für diese Session-ID den Angemeldet-Status und liefert dann, statt wie bisher den 401-Header und die Eingabeaufforderung, einen 200-Header und den Content.

Ich rede die ganze Zeit von einem selbstgeschriebenen Anmeldesystem (PHP-/sessionbasiert), das ohne jegliche spezielle Browserunterstützung auskommt, aber trotzdem in der Lage sein sollte, aussagekräftige Statuscodes zu verwenden. Ohne, dass dabei ein Anmeldefenster für BASIC-AUTH aufpoppen soll...

Grüße,

RIDER