Moin,
Lass dir mal den weiteren Inhalt ausgeben da steht üblicherweise genauer drin was falsch ist.
Bringt (mir) leider nichts:
HTTP/1.1 400 Bad Request
Date: Mon, 08 Apr 2002 13:56:35 GMT
Server: Apache/1.3.12 (Unix) PHP/4.0.6 PHP/3.0.18 FrontPage/4.0.4.3
Connection: close
Content-Type: text/html; charset=iso-8859-1
Das sind nur die Header, die interessanten Sachen stehen im Body. Ich hab das eben mal lokal gemacht:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>400 Bad Request</TITLE>
</HEAD><BODY>
<H1>Bad Request</H1>
Your browser sent a request that this server could not understand.<P>
Client sent malformed Host header<P>
<HR>
<ADDRESS>Apache/1.3.19 Server at fuzzy.homeip.net Port 80</ADDRESS>
</BODY></HTML>
Da siehst du das Problem sofort und kannst es beheben (im Host:-Header hat das http:// nix zu suchen).
\x0d\x0a an Stelle von \r\n bringt nichts. Allerdings kommt die gleiche Meldung wenn ich nur \x0a bzw. \n verwende, weshalb ich mal vermute, dass das nicht das Problem ist.
Ok, nimm aber besser trotdem die von mir genannte Schreibweise, falls du doch mal auf ein komisches System kommst.
Nein, HTTP/1.0 bringt nichts, ähnlicher Output mit dem Zusatz:
Transfer-Encoding: chunked bei HTTP/1.1
Ja, deswegen würde ich HTTP/1.0 nehmen wenn du nicht vorhast einigen zusätzlichen Quellcode mit den Standardeinstellungen von 1.1 zu beschäftigen: Keep-Alive (lässt sich leicht durch einen Connection: Close Header beim Request abstellen) und Chunked-Encoding (lässt sich gar nicht abstellen, höchstens Serverseitig).
btw. auch bei einem HTTP/1.0-Request wird ein HTTP/1.1-Response geliefert.
Das liegt irgendwo im Apache, eigentlich ist es nicht RFC-konform eine 1.1-Antwort auf eine 1.0-Anfrage zu senden, der Idianer macht das trotzdem. Weiss nicht ob es ein bekannter Bug ist, es ist jedenfalls im Archiv auch schonmal aufgefallen.
Das verrückte ist ja, dass es mit http://login:pw@www.domain.de/geschuetzt/ geht! Wenn ich damit eine Datei in einem geschützten Verzeichnis aufrufe und danach eine andere im selben Verzeichns oder einem Subverzeichnis (ohne login:pw@ in der URL) wird nicht nochmal nach PW und Login gefragt, auch wenn ich $PHP_AUTH_USER bzw. $PHP_AUTH_PW abfrage, sind die mit login:pw übergebenen Login- und PW-Angaben vorhanden (getestet mit IE 5.x, NN 4.7 und Mozilla 0.9.9)! D.h. das wäre eigentlich DIE Lösung, nur sie ist nicht RFC-konform :(
Ja, lass das lieber, es gibt keine richtige Lösung die diesem Muster folgt.
... und um eingebundene Bilder, .pdf und sonstiges muss ich mich auch so kümmern, wenn ich das richtig verstehe.
Japp, daher mein Verweis auf das Skript im Archiv, das macht das im großen und ganzen ganz gut.
Da dies so prima mit http://login:pw@www.domain.de/geschuetzt/ funktioniert, bin ich fast versucht RFC RFC sein zu lassen. Hmm, wo könnte es dann Probleme geben?
In allen Browsern die sich an den RFC halten (bin erstaunt dass das der Mozilla nicht macht) fährst du gegen den Baum, ausserdem sind Passwort und Benutzername in der History.
--
Henryk Plötz
Grüße aus Berlin