Sascha Postner und Daniel Jagszent sprechen heute über Weiterleitungen. Welche Arten es gibt und warum man manche bevorzugen sollte. Außerdem gibt es einen kleinen Exkurs in HTTP-Statuscodes und die perfekte 404-Fehlerseite.

Diese Folge jetzt anhören

Weiterleitungsarten und Beispiele

Wir unterscheiden grob in Weiterleitungen, die über direkt über den HTTP-Header erfolgen (.htaccess und PHP) und Weiterleitungen, die erst innerhalb des Dokuments ersichtlich werden (Meta und JavaScript).

  • Meta-Weiterleitung
  • JavaScript-Weiterleitung
  • .htaccess-Weiterleitung mit mod_redirect
    .htaccess-Dateien können nur beim Apache Webserver benutzt werden. In dem Verzeichnis, das umgeleitet werden soll, kann man eine .htaccess-Datei mit dem Inhalt der Beispieldatei erstellen.
    Wobei zu beachten ist, dass die erste URL (”/” in dem Beispiel) immer lokal zu dem Ordner ist, in dem sich die .htaccess-Datei befindet. Die URL, auf die weitergeleitet wird, muss eine vollständige URL sein.
  • .htaccess-Weiterleitung mit mod_rewrite
    Mächtigere Alternative zu mod_redirect, die mit regulären Ausdrücken und boolschen Verknüpfungen sehr komplizierte Weiterleitungen unterstützt.
    Das Beispiel macht das gleiche, wie das mod_redirect Beispiel. Außerdem zeigt es, dass mod_rewrite nicht gerade intuitiv ist.
  • PHP / Skriptgesteuerte Weiterleitung

Links zur Sendung

Erata

Daniel hatte natürlich nicht Recht, als er behauptete, dass 302 Statuscodes die Adresszeile des Browsers nicht verändern.

Diese Folge jetzt anhören

Tags: , , , , ,

Dieser Beitrag wurde am Montag, 27. August 2007 um 00:43 Uhr in der Kategorie Podcast veröffentlicht.
Du kannst einen Kommentar hinterlassen, oder einen Trackback von deiner Seite aus senden.

Kommentare

  • Avatarbild von Thomas Thomas
    am 27. August 2007, 02:03 Uhr

    Hi!
    Yey! Ein Thema mit dem ich mich, wenn ich ehrlich bin, noch nie beschäftigt habe!

    Sprich sehr gute Wahl!
    Hehe PHP ist toll!
    Das “BIST DU DIR SICHER?!” war interessant :D

    http://www.sitepoint.com/article/guide-url-rewriting hier ist ein Tutorial.. damit lerne ich das gerade :D

    Stille… :D

    Thomas

    P.S.: Man hört irgend wie euch beide leise im Hintergrund.. ist ein wenig komisch anzuhören.. Natürlich nicht schlimm ;)

  • Avatarbild von Sascha Sascha
    am 27. August 2007, 02:20 Uhr

    Ich frage mich allerdings weshalb ich mir die Nummer/Ausgabe merken muss, um zu einem bestimmten Thema den passenden Artikel/Podcast zu finden. Ich würde auf die Zahl verzichten, oder besser noch: …/podcast/weiterleitungen
    Denn podcast sagt mir schon um was es geht, und die URL auch.
    “Don’t point the finger” — gut das ich keine eigene Seite habe, … naja.

    Grüße, Sascha

  • Avatarbild von Julian Julian
    am 27. August 2007, 06:20 Uhr

    Naja die erste Anmerkung würde besser zu SiM passen, aber die Nacht wollte mir keinen Schlaf schenken, also kommentiere ich schon jetzt. Hab mir die Sendung aufn iPod und dann gehört.

    Also gleich mal nebenbei: Es wäre intelligent, die Skype Töne bei einer aufnahme abzuschalten ;)

    Also jetzt endlich zum Inhalt der Podcasts:
    Bei den Fehlercodes hat der 403 nicht unbeding was mit dem Nutzer zu tun. Klar, dieser kann ein Verzeichnis aufrufen, auf dass er keinen Zugriff haben soll, aber es ist auch möglich, dass die Rechte versehentlich falsch gesetzt wurden und dadurch der Webserver keinen Lesezugriff hat.

    Ein Beispiel für eine Weiterleitung per Meta wäre z.B. eine Meldung, dass man die Seite verlässt, auch wenn ich das für unnötig halte.

    Eine 302 Weiterleitung wäre z.B. auch innerhalb einer Hoempage möglich: Wenn du in einem Script ein große Sicherheitslücke entdeckst, kannst du temporär auf eine Seite weiterleiten, dass der Bereich bearbeitet wird, oder eine Weiterleitung bei einem Formular zur Erfolgsmeldung usw…

    So und jetzt noch was allgemein zu Technikwürze:
    Mich würde es sehr freuen, wenn ihr den kompletten Beitrag in den Feed packen würdet, dann hätte ich nämlich die gesamten Shownotes auf dem iPod und könnte sie überall anschauen.

    Der wahrscheinlich längste Kommentar von mir / der Welt ;)
    Julian

  • Avatarbild von Matt Matt
    am 27. August 2007, 08:43 Uhr

    Hallo Sascha,
    wir haben uns unter den 1,2 Millionen Menschen in Essen am Wochenende wohl verpasst :D Oder hab ich dich auf einer Ampel gesehen?

    Zur Sendung:
    Warum genau hab ich bisher immer mit Javascript umgeleitet? ;) Bin wieder ein bißchen schlauer. Danke.
    Genau solche Hinweise brauchen Bastler wie ich. Hat mir wie die Sendung zu Crosssitescripting super gefallen.

    So um Julian jetzt nicht den Titel “längster Kommentar der Welt” zu klauen: Schluß :)

    Gruß Matt

  • Avatarbild von supeermario supeermario
    am 27. August 2007, 10:44 Uhr

    hallo,

    danke für euren podcast…
    was ich jetzt nicht rausgehört habe, kann man eine weiterleitung fabrizieren bei der die ursprungs-url beibehalten wird und nur quasi der “server” ein anderer ist?

  • Avatarbild von Daniel Jagzent Daniel Jagzent
    am 27. August 2007, 11:21 Uhr

    @supeermario

    Das geht mit mod_rewrite und mod_proxy – aber dafür muss dann der Ursprungs-Webserver als Proxy für alle Verbindungen herhalten.

    Der URL Rewriting Guide und die Referenz-Doku zu mod_rewrite sagen dir, wie’s geht.

    mod_rewrite ist so umfangreich, dass es den Rahmen dieser Sendung gesprengt hätte.

  • Avatarbild von Sascha Postner Sascha Postner
    am 27. August 2007, 12:37 Uhr

    @Matt:
    Danke für das Lob. Das hört man auch mal gerne. :)

    Ich war auf keiner Ampel. Aber eine Freundin hat mir gerade diesen Link geschickt: Angeblich war das aber das einzig stark beschädigte Straßenbauteil:

    @supeermario:
    Der von DJ angesprochene Proxy für Mod-Rewrite ist allerdings so gut wie nie aktiviert, was vor allem unter Sicherheitsaspekten sehr gut ist. :) Ich hab den auch schon öfter vermisst und dann doch letztlich immer auf veränderte DNS Einträge gesetzt.

  • Avatarbild von Clemens Clemens
    am 27. August 2007, 12:44 Uhr

    Interessante Folge, auch wenn nichts neues für mich dabei war.

    Als Ergänzung vllt noch: Wenn man weiterleiten will und die POST-Daten beibehalten werden sollen, muss man den Statuscode 307 verwenden, die Browser sollen dann allerdings nachfragen (ein sehr bekannter Browser tut das allerdings nicht).

    mod_rewrite wäre mal ne eigene Folge wert, weil es wirklich ein sehr brauchbares und mächtiges Tool ist.

  • Avatarbild von Alexander Alexander
    am 27. August 2007, 13:17 Uhr

    Zu mod_redirect und mod_rewrite

    Ich finde mod_redirect sollte man verwenden wenn man einzelne umleiten will und mod_rewrite ist eher dafür geeignet ganze Blöcke umzuleiten
    Beispiel:
    Alle Seiten von
    http://beispiel/start/
    zu
    http://beispiel/unangemeldet/start/
    umleiten.
    Ähnliches wird ach bei php.net verwendet, denn http://php.net/str_replace führt direkt zum Manualeintrag der Funktion str_replace

    LG Alexander

  • Avatarbild von macx macx
    am 27. August 2007, 14:16 Uhr

    @Julian: Den ganzen Beitrag werden wir nicht in den ID3-Tags einbinden. Das hat mehrere Gründe: Zum einen sind nicht alle Podcatcher kompatibel, bzw. zeigen nur einen Teil einer Nachricht, die anderen können keine Umlaute darstellen und nicht zuletzt wollen wir euch auch hierhin umleiten, damit ihr hier kommentieren könnt. Wir wollen Feedback!

  • Avatarbild von Julian Julian
    am 27. August 2007, 14:20 Uhr

    Ach ja, ein Nachtrag:
    mod_rewrite ist zum Weiterleiten zweckentfremdet, wenn die neuen URIs nicht dynamisch aus der aktuellen Andresse generiert werden müssen.
    Weitere Infos: http://www.drweb.de/htaccess/htaccess_weiterleitugen.shtml

  • Avatarbild von Michel Michel
    am 27. August 2007, 18:32 Uhr

    Interessante Sendung :)

    Schönen Gruß aus Mülheim
    Michel

  • Avatarbild von Simon Simon
    am 27. August 2007, 23:15 Uhr

    Hi,

    wie kann ich denn Meta-Weiterleitungen abschalten? Mir war bisher keine Browsereinstellung dazu bewusst. Sogesehen kann man sagen: Meta-Weiterleitungen kann man genauso beeinflussen, wie Header-Weiterleitungen, denn es ist ein Verhalten, das der Browser implementieren muss – mit einem selbstgebastelten / angepassten Browser geht es also theoretisch schon, Header-Weiterleitungen zu ignorieren.

    Das eigentliche Böse an den Meta-Weiterleitungen ist, dass sie nicht barrierefrei sind. Man kann sich leicht vorstellen, wie ein Benutzer sich fühlt, wenn ein paar Worte einer Seite vorgelesen werden und plötzlich eine andere Seite geladen wird – und der Benutzer weiß nicht, was mit ihr/ihm passiert.

    Wie schon ein Vorkommentator angerissen hat, kann ich mir vorstellen, dass 302 für Wartungsseiten zum Einsatz kommen könnte. Die Alternative wäre, dass das Script, welches die Darstellung aller Seiten kontrolliert, einfach die Wartungsseite als anderen Inhalt anzeigt – das könnte aber von Crawlern als neuer Inhalt indiziert werden, also besser auf eine Wartungsseite weiterleiten.
    Frage ist nur, ob 302 dafür gedacht ist. Denn eigentlich sagt es ja “die Seite, die Du suchst, liegt gerade da und da” – und dann sieht man aber nicht die Seite, die man sucht, sondern die Wartungsseite.

    Zum Abschluss noch einen Artikel, den jeder, der Webapplikationen schreibt, kennen sollte: http://www.theserverside.com/tt/articles/article.tss?l=RedirectAfterPost – der Autor beschreibt, wann man POST und wann GET einsetzen sollte und warum ein Redirect in Verbindung mit POST wichtig ist.

    Viele Grüße, Simon

  • Avatarbild von Moritz Moritz
    am 27. August 2007, 23:54 Uhr

    Der Podcast kam mir ziemlich verplant vor; macht aber auch deutlich das ihr ehrlich über die Sachen redet und nicht einfach Inhalte aus Webseiten vorlest den ich mir auch selbts durchlesen könnte – ich mag es :)

  • Avatarbild von Markus Wulftange Markus Wulftange
    am 28. August 2007, 11:27 Uhr

    Google kann sehr wohl mit HTTP-Weiterleitungen umgehen und bevorzugt diese auch (). Dennoch stimmt es, dass zusätzlich ein Dokument ausgegeben werden sollte, in dem die Weiterleitung manuell ausgeführt werden kann. In den vielen Fällen übernimmt der Webserver dies aber selbstständig.

    Das Smashing Magazine hat ürbigens eine nette Sammlung von 404-Fehlerseiten veröffentlicht ().

  • Avatarbild von Tobias Tobias
    am 28. August 2007, 11:36 Uhr

    In der Area 404 gibt es ein paar ziemlich ausgefallene 404 Seiten als Anregung:
    http://www.plinko.net/404/area404.asp

    Richtig spannend wird´s ja eigentlich erst mit mod_rewrite – vielleicht gibt es ja demnächst einen cast zu diesem Thema?
    Schönen Gruss,
    Tobias

  • Avatarbild von marc thiele marc thiele
    am 28. August 2007, 14:07 Uhr

    Der Einfachheit halber noch der Link zur 404 Sammlung von Smashing Magazine:

    http://www.smashingmagazine.com/2007/08/17/404-error-pages-reloaded/

  • Avatarbild von Markus Markus
    am 29. August 2007, 17:49 Uhr

    Hallo,
    informativer Podcast, bin eben durch Zufall drauf gestoßen.
    Aber gleich mal ein Hinweis: Eure Blog-URLs ohne ID und so nennt man entweder Nice URLs oder Permalinks (http://de.wikipedia.org/wiki/Permalink).

    Ansonsten – Weiter so!

    Gruß,
    Markus

  • Avatarbild von Herr Voß Herr Voß
    am 29. August 2007, 18:49 Uhr

    Sehr interessantes Thema – leider ein wenig zu chaotisch für meinen Geschmack. Vielleicht solltet ihr vor einer Sendung zumindest kurz besprechen, was ihr erzählen wollt. ;-)

    An den anderen Kommentaren kann man ja auch schon sehen, dass da einiges durcheinander gegangen ist.

    • Short- oder Nice-URLs sind URLs, die vortäuschen, dass man es mit statischen HTML-Seiten zu tun hat.
    • Permalinks sind quasi Aliase für URLs, die sich eventuell ändern könnten.
    • Das hat nichts zu tun mit “Good URLs don’t change” – Dabei geht es darum, dass unter URLs immer der gleiche Content abzurufen ist. Wenn Dich also vor 10 Jahren mal jemand verlinkt hat, sollte der Link immer noch funktionieren, auch wenn man mittlerweile 3x das CMS gewechselt hat. Recht schwierig das immer durchzuhalten. Zumal man ja auch mal Content rausschmeisst.
    • Clientseitige Weiterleitung, die nicht durch den Benutzer ausgelöst werden (Link “Bitte klicken Sie hier für unsere neue Homepage) können AFAIK nicht barrierefrei sein.

    Ich persönlich halte die Wichtigkeit von lesbaren URLs für überschätzt. Schön: Sollte Google den verwendeten Wörtern dort einen Wert zuerkennen, kann man es deswegen benutzen. Das ist auch der Grund, warum ich das so mache. Aber als normaler Surfer gebe ich doch weder URLs mit Parametern noch mit lauter Slashes ein, oder? Oder kommt IRGENDWER von Euch hier auf die Seite und gibt in der Browserzeile mehr als technikwuerze.de ein? Inzwischen lass ich sogar das .de weg :-D

    Der Hinweis auf den A List Apart Artikel ist klasse. Da sind tolle Tipps drin.

    Macht weiter Jungs! Ihr seid trotz meine kleinen Kritik hier der beste Technik-Podcast, den ich kenne und selbst in meiner Gesamtenwertung seid ihr in den Top5 (Von 20 oder so) ;-)

  • Avatarbild von Konstantin Klein Konstantin Klein
    am 3. September 2007, 14:15 Uhr

    Simon fragt weiter oben, ob sich die Weiterlietungen auschalten lassen:
    Ja. dazu in Opera (der meiner Ansicht nach von Natur aus anpassbarste Browser) nach (in der Englischen Version) Tools->Preferences->Advanced->Network->enable automatic redirection (Häkchen raus)
    und dann in Firefox mit dem Add-On Webdeveloper (das übrigens absolut empfehlenswert ist) unter Disable->Disable Meta redirects (Häkchen hin)
    Bei Error 404 gibts für den Standard-Nix-mit-Technik-am-Hut-hab-Surfer den netten IE, der aus einem simplen 404-error was schönes zaubert und dazu auffordert die eingabe zu überprüfen.
    temporäre umleitung kann man vielleicht gebrauchen, wenn man die seite 2 mal gehostet hat (ausirgendwelchen gründen) und dann bei der einen was umbaut und solange auf die alternative Seite umleitet.

  • Avatarbild von Martin Martin
    am 4. September 2007, 12:21 Uhr

    Wollte nur mal anmerken das man bei einer Weiterleitung per Meta oder Java Script generell vollständige URL’s verwenden sollte.
    Und das nicht nur weil es den Spezifikationen entspricht, sondern ältere Browser dies sonst nicht unterstützen. Ein weiterer Punkt ist auch dieser “Im Cache” link bei Google. Wenn in der Aufgerufenen Seite eine Weiterleitung mit relativer URL verwendet wird, kann diese natürlich nicht funktionieren, da sich die Seite auf Google befindet.

Und was hast du zum Thema zu sagen?

Fülle bitte alle mit *-gekennzeichneten Felder aus.


Du darfst Textile verwenden, um deinen Beitrag auszuzeichen.