Weiterleitung
Sanne
- php
0 Liza0 Tom0 Thomas Luethi
Hi zusammen!
Ich möchte wenn meine Startseite aufgerufen wird mit PHP auf einen Unterordner umleiten.
Nun wollte ich mal fragen ob das irgendwelche Nachteile haben kann.
Gibt es da z.B. Probleme bei manchen Browsern?
Wie ist das mit Meta Tags? Können die auch in die index.html oder müssen die dann nur in den Unterordner?
Danke!
Hallo,
Ich möchte wenn meine Startseite aufgerufen wird mit PHP auf einen Unterordner umleiten.
Nun wollte ich mal fragen ob das irgendwelche Nachteile haben kann.
Ja, es wird nicht funkionieren. :-) Da PHP auf dem Server ausgeführt wird, kannst du keine Weiterleitung von Seiten des Anwenderbrowsers umsetzen. Eine Weiterleitung in PHP würde der Anwender gar nicht zu sehen bekommen.
Für deinen Wunsch gibt es die Möglichkeiten einer Weitereitung mittels meta-Tag (refresh) oder mit Hilfe von JS. Der Meta-Tag funktioniert fast immer, JS kann der Anwender ausgeschaltet haben.
Weiterleitungen haben eigentlich nur eine "negative" Auswirkung auf einige Suchmaschienen, müssen sie aber nicht.
Ciao
Liza
Hallo Liza,
Ja, es wird nicht funkionieren. :-) Da PHP auf dem Server ausgeführt wird, kannst du keine Weiterleitung von Seiten des Anwenderbrowsers umsetzen. Eine Weiterleitung in PHP würde der Anwender gar nicht zu sehen bekommen.
Eine Weiterleitung in PHP...
Wenn Du die Header("Location: ...") -Funktion meisnt, die bekommt der "Anwender" (Client) sehr wohl zu sehen. Er muss dann nämlich den erheuten Request auf die neue Location auslösen.
Grüße
Tom
Hi
Nein er bekommt das nicht zu sehen da der request bereits auf dem Server ausgeführt wird und der Client nur das Ergebnis der Action des PHP-Scriptes zu sehen bekommt. Da gibt es keine Anfragen von Seiten des Clienten an den Server. Meiner Meinung nach... entspricht auch den Ergebnissen der Praxis
Gruß DAve
Hi Dave,
wenn die Funktion header('Location: ...'); in PHP aufgerufen wird, bekommt der Client ein "Moved temporarely" ErrCode = 302 mit der neuen Location als Datenwert geschickt.
Er löst dann den erneuten Request auf die neue URL aus und sendet, fals vorhanden, sogar Cookies mit.
So kann man wunderbar checken, ob ein Client Cookies annimmt.
Grüße
Tom
Hallo,
der Nutzer bekommt also faktisch nichts zu sehen, es sei denn er überprüft clientseitige Internetlogs.
Aber die Abfolge war mir so nicht bewußt. Der Tipp mit dem Cookietest klingt sehr interessant.
Ciao
Liza
Hi Liza,
der Nutzer bekommt also faktisch nichts zu sehen, es sei denn er überprüft clientseitige Internetlogs.
Wenn er einen 08/15-Browser benutzt, merkt er das i.d.R. nicht.
Es gibt aber auch Browser, bei denen man die Funktion sperren kann.
Grüße
Tom
Hi Dave,
wenn die Funktion header('Location: ...'); in PHP aufgerufen wird, bekommt der Client ein "Moved temporarely" ErrCode = 302 mit der neuen Location als Datenwert geschickt.
Er löst dann den erneuten Request auf die neue URL aus und sendet, fals vorhanden, sogar Cookies mit.
So kann man wunderbar checken, ob ein Client Cookies annimmt.
Grüße
Tom
Oh das hat ich gar ne bedacht... danke für den Hinweis... Man lernt doch nie aus... *grins*
Gruß Dave
Hallo Dave, Hi @ all
Oh das hat ich gar ne bedacht... danke für den Hinweis... Man lernt doch nie aus... *grins*
Bitteschön,
dafür sind wir ja hier zusammen.
Kann _ich_ vielleicht gleich noch die Frage stellen, woher beim HTTP-Request der Client weiß, dass nun nix mehr kommt. Wann wird der Port wieder geschlossen? Wer könnte das bitte mal dediziert beschreiben?
Beim POST zum Server steht ja im Header die Größe der Anfrage in Byte. Was ist aber bei der Antwort vom Server?
Grüße
Tom
Liebe RFC-feste Forumler,
die Frage war durchaus ersnt gemeint. Verzeiht bitte, wenn ich da in der Überschrift noch mal etwas lauter werde. Ich wollte nun nicht extra einen neuen Thread aufmachen.
Ich bin durch die Diskussion hier wieder darauf gestoßen worden, dass ich schon lange eine verständliche und erschöpfende Antwort darauf suche. Inzwischen habe ich bestimmt 40 Artikel zum Thema aus Google durchgelesen und mindestens dreimalsoviel als oberflächlich weggeklickt. Viel schlauer bin ich noch nicht (etwas lernt man immer).
Kann _ich_ vielleicht gleich noch die Frage stellen, woher beim HTTP-Request der Client weiß, dass nun nix mehr kommt. Wann wird der Port wieder geschlossen? Wer könnte das bitte mal dediziert beschreiben?
Beim POST zum Server steht ja im Header die Größe der Anfrage in Byte. Was ist aber bei der Antwort vom Server?
Ja, die etwas ausführlichere Beschreibung eines HTTP-Requests würde mich also begeistern.
Liebe Grüße
Tom
hi,
Kann _ich_ vielleicht gleich noch die Frage stellen, woher beim HTTP-Request der Client weiß, dass nun nix mehr kommt. Wann wird der Port wieder geschlossen? Wer könnte das bitte mal dediziert beschreiben?
der server gibt in der antwort die anzahl an bytes, die der client zu erwarten hat, mit - also braucht dieser nur noch mitzählen.
geh doch mal auf die seite vom Michael Schroepl hier aus dem forum, der stellt ein tool zum anzeigen von http-headern bereit.
damit schaue ich mir jetzt z.b. mal an, was ein GET-request meines browsers auf die adresse http://www.heise.de/ für http-header auslöst: http://www.schroepl.net/cgi-bin/http_trace.pl?url=http%3A%2F%2Fwww.heise.de%2F&method=GET&version=HTTP%2F1.0
dort hast du zunächst eine auflistung "HTTP request received from browser", also das was dein browser an micheals server geschickt hat.
darunter folgt "HTTP request sent to server", also welche anforderung jetzt an den heise-server geschickt wurde.
und darunter findest du dessen response, "HTTP response headers received from server".
und dort siehst du u.a die angabe
Content-Length: 7123
der client weiss jetzt also, dass er vom server eine antwort von 7123 zeichen länge zu erwarten hat.
gruss,
wahsaga
Hallo wahsaga,
Content-Length: 7123
der client weiss jetzt also, dass er vom server eine antwort von 7123 zeichen länge zu erwarten hat.
Danke. Dieser Meinung war ich auch immer, bis ich dann die vielen (unterschiedlichen) Beschreibungen gelesen habe.
Insbesondere wurde immer wieder gesagt, dass der Client die Verbindung aufbauen würde und der Server sie beenden würde.
"Für den Fall, dass die Anzahl der zu übertragenden Bytes nicht feststeht, beendet der Server die Verbindung"
Nun hab' ich aber auch noch im Kopf, dass es sich bei HTTP um ein verbindungs- und zustandsloses Protokoll handeln soll. Hab ich mir da 'was Falsches gemerkt?
Und dann hatte ich mal vor längerer Zeit ein Ausgabe-Script (endlos.php) geschrieben, dass solange Daten ausgegebn hat (mit flush() dazwischen), bis der Client dicht gemacht hat.
Wie passt das nun alles zusammen?
Über weitere GUTE Links (bitte nicht die RFCs, die sind mir zu englisch unverständlich, hab ich natürlich auch schon) würde ich mich freuen. Diese Grauzone in meinem Wissen möchte ich doch nun endlich mal hell erleuchten bis ins letzte Bit.
Grüße
Tom
Hallo Tom,
"Für den Fall, dass die Anzahl der zu übertragenden Bytes nicht feststeht, beendet der Server die Verbindung"
Nun hab' ich aber auch noch im Kopf, dass es sich bei HTTP um ein verbindungs- und zustandsloses Protokoll handeln soll.
Ja.
Hab ich mir da 'was Falsches gemerkt?
Nein. Jetzt kommt das große 'Aber':
Wie wird eine Resource über HTTP ausgeliefert?
Einfachstes Beispiel:
1. Der Client öffnet eine TCP-Verbindung zum Server.
2. Der Client fordert die Resource an.
3. Der Server liefert diese Resource an den Client.
4. Der Server schließt die Verbindung.
'Verbindung' ist hier eine Ebene tiefer: Nämlich auf TCP-Ebene. Auf HTTP-Ebene gibt es tatsächlich keine Verbindungen. Auf TCP-Ebene dagegen schon.
Wenn der Server die Dateigrößen genau kennt ist auch folgende Möglich:
1. Der Client öffnet eine TCP-Verbindung zum Server.
2. Der Client fordert die Resource an.
3. Der Server liefert diese Resource an den Client mitsamt der Dateigröße.
4. Der Client fordert eine weitere Resource an.
5. Der Server liefert diese weitere Resource an den Client mitsamt der Dateigröße.
6. Wdh. 4-5 ein paar Mal
7. Der Client sendet bei der letzen Resource die Anfrage mit, dass die Verbindung geschlossen bei der nächsten Resource werden soll.
8. Der Server liefert die letzte Resource aus.
9. Der Server schließt die Verbindung.
Schritt 7 ist optional, der Server kann auch 'von alleine' (per Konfiguration) angewiesen werden, pro TCP-Verbindung maximal n Resourcen auszuliefern. Der Server gibt bei jeder Resource mit an, ob er vorhat, die Verbindung daraufhin zu schließen. (Connection: close als Response-Header)
In HTTP/1.1 gibt es außerdem noch eine bestimmte Kodierung: 'Transfer-Encoding: chunked'. Wenn der Server diesen Response-Header mitsendet, wird die Datei in lauter kleine Teile aufgeteilt. Der Server sendet dann ein Byte, das die Menge an Bytes enthält, die als nächstes folgen wird. Danach kommt diese Menge an Bytes. Danach kommt wieder so ein Längen-Byte, gefolgt von den Bytes selbst. Wenn die Datei zuende ist, wird als Längen-Byte 0 gesendet. So kann 'Connection: keep-alive' (d.h. TCP-Verbindung wird für weitere Resourcen offen gehalten) auch funktionieren, wenn die Größe der Resource dem Server unbekannt ist (serverseitige Scripte).
Viele Grüße,
Christian
Hallo Christian,
vielen Dank für die ausführliche Erläuterung. Sollte Die dazu noch mal irgendwann ein Listing in die hand falln, wäre ich dafür dankbar.
Es ging im Wesentlichen um das Verständnis, ob auf diese Weise eine Dauerverbíndung zwischen Server und Client für unser "Schiffeversenken" [pref:t=61630&m=347764] erhalten werden könnte.
Aber wahrscheinlich würde einer der beiden bei zu langen Zügen Timeout generieren?
Grüße
Tom
Hi dave,
Nein er bekommt das nicht zu sehen da der request bereits auf dem Server ausgeführt wird und der Client nur das Ergebnis der Action des PHP-Scriptes zu sehen bekommt.
Hast du einen Link dazu? Oder ein RFC?
Da gibt es keine Anfragen von Seiten des Clienten an den Server. Meiner Meinung nach... entspricht auch den Ergebnissen der Praxis
"'cause you don't see it' is no reason not to search for it" (anonymer amerikanischer kernforscher, afaik)
Grüße aus Barsinghausen,
Fabian
Hallo,
wenn die Umleitung per header() passiert, könnte nur die Suchmaschinen streiken. Bei Metatag wird ggf. nur die Startseite selber ausgewertet.
Grüße
Tom
Hallo,
Als Ergaenzung zum bisher geschriebenen:
Ich möchte wenn meine Startseite aufgerufen wird mit PHP auf einen Unterordner umleiten.
header("Location: http://www.example.com/unterordner/");
macht eine HTTP-302-Umleitung.
Wichtig dabei: die URL muss absolut sein, also mit http:// anfangen.
http://www.php.net/manual/de/function.header.php
Nun wollte ich mal fragen ob das irgendwelche Nachteile haben kann.
Eigentlich nicht.
Bereits in HTTP 1.0 (aus dem Jahr 1996) sind 302-Header festgelegt.
Wenn eine Software _das_ nicht kann, dann hat sie noch ganz andere
Probleme, z.B. mit virtuellen Hosts (mehrere Domains auf einer IP),
und ist im heutigen Internet nicht mehr zu gebrauchen.
Gibt es da z.B. Probleme bei manchen Browsern?
Ganz selten, z.B. wenn der Benutzer es absichtlich abgeschaltet hat.
Fuer diesen Fall sollte man gemaess der HTTP 1.1 Spezifikation
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3
_nach_ dem Header noch eine kurze HTML-"Datei" mit einem normalen
Link auf die Folgeseite ausgeben.
Die "ideale Loesung" (die sogar valide ist) geht also so:
<?php
header("Location: http://www.example.com/unterordner/");
print("<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">\n");
print("<title>Umleitung</title>\n");
print("<p><a href='http://www.example.com/unterordner/'>Hier geht's weiter...</a></p>\n");
?>
Wie ist das mit Meta Tags? Können die auch in die index.html oder müssen die dann nur in den Unterordner?
Welche "Meta Tags" meinst Du?
Das Umleitungs-Zeugs
http://selfhtml.teamone.de/html/kopfdaten/meta.htm#weiterleitung
solltest Du eigentlich nicht benutzen, wenn Du schon PHP hast,
und wenn, dann nur mit einer Wartezeit groesser als 0, z.B. mit 5 oder 10 Sekunden,
sonst machst Du den Leuten den Zurueck-Knopf bzw. die History kapputt.
Gruesse,
Thomas