Hallo eddie,
Wo bitteschön hast Du das base64_encode her?
RFC 1945 zu HTTP 1.0 Abschnitt 11 "Access Authentication" nicht gelesen?
Doch. Und in RFC 2617 (die Spezifikation zur Authentifizierung in HTTP/1.1) steht auch etwas von wegen base64, allerdings verstehe ich Deinen Bezug nicht?
- Bei HTTP ist ein Konstrukt http://benutzer:passwort@rechner:port/pfad ungültig. (Siehe http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.2 - dort steht nichts von Benutzernamen oder Passwort)
Laut http://de2.php.net/manual/en/wrappers.http.php ist die auch irrelevat;
Hmmm? Wo steht da, dass die irrelevant ist? RFC2616 ist der RFC, der offiziell spezifiziert, wie ein HTTP-URI auszusehen hat. Wenn ich davon spreche, dass irgendwas kein gültiger URI ist, dann führe ich die Betrachtung rein theoretisch durch (d.h. ich vergleiche den URI mit dem Standard); natürlich weiß ich, dass diverse Programme diese Art von "Erweiterung" trotzdem verstehen.
Der Einfachheit halber - hört sich für mich an, als hätte man bei fopen() eine schwerere Alternative.
Ja, beispielsweise fopen ('http://.../', 'r', $user, $passwort); - was allerdings ziemlich inkonsistent gegenüber anderen Protokollen wäre.
Schlußendlich stimme ich Dir zu, wenn Du Dich auf Browser beziehst, in Ermangelung einer Alternative beim Gebrauch von fopen() stört mich aber gerade das "der Einfachheit halber" ;)
Ich habe nicht gesagt, dass ich das Verhalten von PHP schlecht finde und "der Einfachheit halber" habe ich absolut nicht abwertend, sondern in diesem Fall eher aufwertend gemeint. Ich wollte in meiner Antwort auf Dein Posting nur zusätzlich drauf hinweisen, dass man diese Konstruktion bei PHP zwar bedenkenlos verwenden kann, bei etwas anderem aber tunlichst die Finger davon lassen sollte.
Viele Grüße,
Christian