nicht angemeldet
Header Location - sicher?
Hi Leute, ich habe ein kurze und bündige Frage:
Wird eine 'Location: .........' - Anweisung im Header unbedingt ausgeführt, oder kann es Probleme geben ( alter/imkompatibler Browser, darf ein User Headeranweisungen ignorieren ? ),
so dass der User nicht redirected ( english rules! ) wird?
Dank im Voraus,
Christian
-
hi!
Wird eine 'Location: .........' - Anweisung im Header unbedingt ausgeführt, oder kann es
Probleme geben ( alter/imkompatibler Browser, darf ein User Headeranweisungen ignorieren ? ),
so dass der User nicht redirected ( english rules! ) wird?Sichergehen kannst du natürlich nicht bei allen Browsern, dass sie jeden HTTP-Header korrekt interpretieren und ausführen. Aber Netscape Navigator und Internet Explorer unterstützen das auf jeden Fall, also ist schonmal ein Großteil der Nutzer abgedeckt. Zu anderen Browsern kann ich momentan leider nichts sagen.
Das hat aber nichts mit HTML zu tun.
bye, Frank!
-
Hi Frank,
Sichergehen kannst du natürlich nicht bei allen Browsern, dass sie jeden HTTP-Header korrekt interpretieren und ausführen. Aber Netscape Navigator und Internet Explorer unterstützen das auf jeden Fall, also ist schonmal ein Großteil der Nutzer abgedeckt. Zu anderen Browsern kann ich momentan leider nichts sagen.
Nun, das wichtigste war eigentlich, dass der User keine Möglichkeit hat, gewisse Header-Anweisungen zu skippen. Wenn ich mich recht entsinne, ist die 'Location:...'-Anweisung
seit HTTP1.1 implementiert, d.h. die Browser sollten das eigentlich können.....Das hat aber nichts mit HTML zu tun.
Yip, da hast du natürlich recht ;-) War ein wenig in Eile, musste naemlich zum Essen....
bye, Frank!
Ciao, Christian
-
Hi,
Nun, das wichtigste war eigentlich, dass der User keine Möglichkeit hat, gewisse Header-Anweisungen zu skippen. Wenn ich mich recht entsinne, ist die 'Location:...'-Anweisung
seit HTTP1.1 implementiert, d.h. die Browser sollten das eigentlich können.....richtig. Um die HTTP1.0-Browser zufriedenzustellen, solltest Du zusätzlich einen Content-type und eine kurze Seite mit Link ausgeben:
print "Location: $uri\n";
print "Content-type: text/html\n\n";
print "This page has moved: <a href="$uri">$uri</a>";Dazu vielleicht noch ein Status 301 oder 302, je nach Bedarf :-)
Cheatah
-
Hi!
ist die 'Location:...'-Anweisung
seit HTTP1.1 implementiert, d.h. die Browser sollten das eigentlich können.....richtig.
Nee, falsch. Der Location-Header tauchte bereits in der HTTP/1.0-RFC auf (Kapitel 10.11 in http://www.ietf.org/rfc/rfc1945.txt). In HTTP/1.1 kam lediglich das Content-Location Feld dazu, welches rein informativ angibt, wo der eigentliche Speicherort einer Resource ist. Z.B. wuerde mir das sagen, dass die Startseite von teamone auf www.teamone.de/index.htm zu finden ist, wenn ich nur www.teamone.de/ anfordere (Kapitel 14.15 in http://www.ietf.org/rfc/rfc2068.txt).
Das heisst aber nicht, dass der IE2, der zumindest kein HTTP/1.1 kann (ob er 1.0 kann, weiss ich nicht, es gab auch mal 0.9), mit dem Location-Header zurechtkommt. Hat zumindest bei einem Versuch von mir jetzt nicht geklappt. Falls mir jemand einen Server nennt, auf dem definitiv keine virtuellen Hosts gefahren werden (um auf die zuzugreifen, braucht man HTTP/1.1), kann ich da noch etwas weiter rumprobieren.
Calocybe
-
Hi,
ist die 'Location:...'-Anweisung
seit HTTP1.1 implementiert, d.h. die Browser sollten das eigentlich können.....richtig.
Nee, falsch. Der Location-Header tauchte bereits in der HTTP/1.0-RFC auf
stimmt, das habe ich falsch behalten, sorry. Die Aussage, daß der Location-Header nicht unbedingt sicher ist, bleibt aber bestehen, denn wie Du selbst sagst:
Das heisst aber nicht, dass der IE2, der zumindest kein HTTP/1.1 kann (ob er 1.0 kann, weiss ich nicht, es gab auch mal 0.9), mit dem Location-Header zurechtkommt.
Nicht alle Browser interpretieren den Header, darum ist ein Header der Art, wie ich ihn beschrieben habe, auf jeden Fall besser.
Hat zumindest bei einem Versuch von mir jetzt nicht geklappt.
Weiß jemand, welche Browser Location nicht interpretieren?
Und wo wir gerade beim Thema sind: Habe ich es richtig in Erinnerung, daß HTTP/1.0 kein HTTP_HOST liefert?
Cheatah
-
Moin Cheatah!
Nicht alle Browser interpretieren den Header, darum ist ein Header der Art, wie ich ihn beschrieben habe, auf jeden Fall besser.
Yepp.
Und wo wir gerade beim Thema sind: Habe ich es richtig in Erinnerung, daß HTTP/1.0 kein HTTP_HOST liefert?
Sehr wahrscheinlich ja. Der Header "Host" wurde erst mit HTTP/1.1 eingefuehrt. Dieser Header ist es, der mehrere virtuelle Hosts ermoeglicht. Denn bei dieser Situation wird immer eine TCP-Verbindung zu *einer* IP-Adresse an *einen* Port aufgebaut. Nur dadurch, dass der Host-Header mitgesendet wird (der einfach den Servernamen im Klartext enthaelt, also z.B. einfach www.teamone.de), weiss der Webserver, von welchem der virtuellen Hosts der Client was will. Man hat dies in HTTP/1.1 eingefuehrt, um IP-Adressen zu sparen, von denen es nun mal nur so ca. 4 Milliarden gibt (von denen sehr viele nicht benutzt werden koennen).
Der Host-Header ist in HTTP/1.1 Pflicht. Ein Browser, der nur die v1.0 spricht, kann gar nicht oder nur mit viel Glueck auf einen Server zugreifen, auf dem mehrere virtuelle Hosts laufen. Ein Beispiel ist eben der IE2, deshalb hatte ich nach einer Website ohne VHosts gefragt.
Calocybe
-
Hi,
Und wo wir gerade beim Thema sind: Habe ich es richtig in Erinnerung, daß HTTP/1.0 kein HTTP_HOST liefert?
Sehr wahrscheinlich ja. Der Header "Host" wurde erst mit HTTP/1.1 eingefuehrt.
danke :-)
Der Host-Header ist in HTTP/1.1 Pflicht. Ein Browser, der nur die v1.0 spricht, kann gar nicht oder nur mit viel Glueck auf einen Server zugreifen, auf dem mehrere virtuelle Hosts laufen. Ein Beispiel ist eben der IE2, deshalb hatte ich nach einer Website ohne VHosts gefragt.
Und genau deshalb hatte ich gefragt ;-)
Cheatah
-
Moins Jungs, vielen Dank für die Info, hat mir gut weitergeholfen!
Christian
-
-
-
-
-
-
-