Weiterleitung per Skript: Warum wird sie nicht endlich ersatzlos gestrichen?

Aber dieses Problem hast du doch bei Weiterleitung per Skript eher noch viel häufiger. Du kannst natürlich immer unterstellen, dass du einen Browser hast, der nicht das macht, was er tun soll. Aber die Bedeutung von Weiterleitung ist klar definiert und ein standardkonformer Browser wird die neue Adresse aufsuchen.

schmidt-webdesign.net

Damit hast Du natürlich (fast) Recht. Perfekt funktionierend und perfekt unterstützt wird in Standard-HTTP aber wirklich nichts. Denn gerade mangelnde Unterstützung und mangelnde Perfektion hat zur (halbherzigen) Entwicklung so mancher Script-Erweiterung(s-Katastophe) geführt.

Und im künftigen Web 2.0 wird ohne JavaScript ohnehin nixmehr perfekt funktionieren ...

Sind so kleine Schnäpse, schauen still und stumm.
Dürft ihr nicht von trinken, hauen euch sonst um.

Sind so große Biere, locken kühl und frisch.
Halt' sie euch vom Leibe, liegt sonst unterm Tisch.

Sind so große Gläser, seid ihr noch bei Trost?
Müsst nicht alles glauben, haut das Zeug weg - Prost!

Gefunden: http://blogex.schmidt-webdesign.net/

minhen

Optimizer schrieb:

Dann, wenn man weitergeleitet wurde, funktioniert der Zurück-Button des Browsers nicht mehr. Hass!!

Da solltest du deinen Ärger an die richtige Adresse richten: dein Browser.
Es gibt keinen technischen Grund dass der Zurück-Button dann nicht mehr funktioniert. Der Opera-Browser demonstriert das wunderbar. Also nicht über Webseiten aufregen, wenn der Browser bzw dessen Entwickler schuld sind

Man mit Meta-Tags übrigens auch eine Weiterleitung innerhalb von 0 Sekunden machen. Wenn du den Weiterleitungstext zu sehen bekommst, dann ist das meistens Absicht.
Ansonsten hast du natürlich recht, dass solche Weiterleitungen bescheuert sind. Speziell alles mit "klicken sie hier" ist ohnehin unter aller Sau

ten

minhen schrieb:

Speziell alles mit "klicken sie hier" ist ohnehin unter aller Sau

nö, ich finde das gut!
automatische weiterleitungen sind immer mies. am schlimmsten ist es, wenn eine seite mal kurz aufflackert. clickt man den 'back button' dann kommt man wieder auf die weiterleitung und wird sofort wieder zurückgebeamt (erst mit blättern in der history kommt man wieder da hin, wo man mal war). da klick' ich mich lieber selber durch links...
:xmas2:

minhen

Erstens habe ich das Wörtchen "hier" nicht aus reinem Spaß an eckigen Klammern fett geschrieben sondern aus einem bestimmten Grund. Bei dem Satz geht es also um etwas völlig anderes, was dir offensichtlich komplett entgangen ist.

Auch das "sofort wieder zurückbeamen" ist eine Sache des Browsers und nur des Browsers. Wie gesagt, Opera macht nicht mal ansatzweise Probleme beim Zurück-gehen. Von so einem Schwachsinn wie beim IE Formulardaten nochmal abzusenden oder eben auch in der Gegend "Rumgebeame" kann überhaupt keine Rede sein. Schöner Browser halt.
Aber um den konkreten Browser geht es gar nicht. Viel mehr geht es darum, dass ihr eure Browserimplementation den Webseiten vorwerft. Und die können nun wirklich nichts dafür, dass ihr den Browser verwendet, den ihr eben verwendet.

minhen schrieb:

Optimizer schrieb:

Dann, wenn man weitergeleitet wurde, funktioniert der Zurück-Button des Browsers nicht mehr. Hass!!

Da solltest du deinen Ärger an die richtige Adresse richten: dein Browser.

Auch das "sofort wieder zurückbeamen" ist eine Sache des Browsers und nur des Browsers.

Der Browser verhält sich standardkonform. Es ist einfach nicht die Idee von Weiterleitung per Skript, diese als Ersatz für eine Standard HTTP Weiterleitung zu verwenden.

Und es ist auch btw. überhaupt nicht die Aufgabe des Browsers, schlechte Seiten angenehm darzubieten oder gar Fehler zu korrigieren. Das ist genau der Mist, weswegen das Web so verseucht ist.

geeky

Hmm, für Weiterleitungen für Nicht-Hauptdomains auf Hauptdomain benutze ich auch das

<script type="text/javascript">
this.location.replace("http://www.hauptdomain.de");
</script>

<noscript>
<p>Bitte besuchen Sie <a href="http://www.hauptdomain.de">http://www.hauptdomain.de</a></p>
</noscript>

Einfach aus dem Grund ne Platzhalter-Seite mit nem blöden "Klicken Sie hier" zu sparen.
Sollte ich da auch auf replace verzichten, damit der Back-Button noch funzt? Ich weiss nich so recht warum ich den User dann zurück auf ne Seite ohne Content lassen soll ?

(oder benutze ich die Weiterleitung über den HTTP-Header, hmm mal bei Gelegenheit nachgucken...)

geeky schrieb:

(oder benutze ich die Weiterleitung über den HTTP-Header, hmm mal bei Gelegenheit nachgucken...)

Ja genau.

Reyx

Gegenfrage: Wieso brauchst du unbedingt eine Weiterleitung?

I.d.R. wäre es viel Besucherfreundlicher, den erwarteten Inhalt einfach unter der erwarteten Adresse bereit zu stellen! Punkt.

Und wenn (z.B. bei Domainumzügen oder was weiß ich) tatsächlich mal eine Weiterleitung nötig ist, dann nimm eine HTTP-Weiterleitung! Die ist wesentlich abstraker und basiert nicht auf JavaScript. Zwar können HTTP-Weiterleitungen auch geblockt werden, aber dies ist in der Praxis eher unwahrscheinlich, wohingegen JavaScript schon gerne bei "nicht vertrauenswürdigen" Seiten deaktiviert wird.

Trotzdem: Die einzig vernünftige Lösung ist, den Inhalt einfach da anzubieten, wo der Besucher ist. Nichts Verzweifung, nichts Weiterleitung.

minhen

Optimizer schrieb:

minhen schrieb:

Optimizer schrieb:

Dann, wenn man weitergeleitet wurde, funktioniert der Zurück-Button des Browsers nicht mehr. Hass!!

Da solltest du deinen Ärger an die richtige Adresse richten: dein Browser.

Auch das "sofort wieder zurückbeamen" ist eine Sache des Browsers und nur des Browsers.

Der Browser verhält sich standardkonform.

Nein, das Verhalten ist nicht standardkonform. Also ein nicht-standardkonformes Verhalten das dem Nutzer auch noch "schadet" indem es den Zurück-Button nutzlos macht. Muss man dazu noch mehr sagen?
Wir können ja ein Spielchen spielen. Du suchst einen Standard der das "Zurück-Button zerstörende Verhalten" bei einer Weiterleitung mit z.B. Meta-Tags standardkonform macht und nachdem du nichts gefunden hast, zeige ich die relevanten Stellen in der HTML 4-Spezifikation, ok? Im Anschluß können wir dann noch gemütlich über die Semantik von Laden eines Dokuments durch den User-Agent diskutieren um uns geekys Weiterleitungsart anzusehen.

Es ist einfach nicht die Idee von Weiterleitung per Skript, diese als Ersatz für eine Standard HTTP Weiterleitung zu verwenden.

Das ist korrekt und auch der Grund weswegen obiges Verhalten nicht standardkonform ist.

schmidt-webdesign.net

Reyx schrieb:

Gegenfrage: Wieso brauchst du unbedingt eine Weiterleitung?

I.d.R. wäre es viel Besucherfreundlicher, den erwarteten Inhalt einfach unter der erwarteten Adresse bereit zu stellen! Punkt.

Und wenn (z.B. bei Domainumzügen oder was weiß ich) tatsächlich mal eine Weiterleitung nötig ist, dann nimm eine HTTP-Weiterleitung! Die ist wesentlich abstraker und basiert nicht auf JavaScript. Zwar können HTTP-Weiterleitungen auch geblockt werden, aber dies ist in der Praxis eher unwahrscheinlich, wohingegen JavaScript schon gerne bei "nicht vertrauenswürdigen" Seiten deaktiviert wird.

Trotzdem: Die einzig vernünftige Lösung ist, den Inhalt einfach da anzubieten, wo der Besucher ist. Nichts Verzweifung, nichts Weiterleitung.

Vielleicht möchte man sich aber mal mit einer neuen Technologie wie z.B. ASP.NET auseinandersetzen, oder (versuchsweise) einem vertrauten Benutzerkreis Dinge wie das tägliche SuDoKu-Rätsel oder andere, interaktive Sachen bereitstellen etc. etc. ...

Wenn man dann (zufällig) über einen eigenen Webserver verfügt (das soll wohl bei fast allen WEB-Entwicklern der Fall sein), drängt sich die (Not-) Lösung der Umleitung von einer permanenten, statischen auf eine sich täglich ändernde dynamische IP förmlich auf. Ist es wenig später eine PHP-/MySQL-Anwendung die getestet werden muss, so ist diese ebenfalls mit nur wenigen Handgriffen verfügbar. Und ALAX-Anwendungen entwickeln macht über einen entfernten Server absolut keinen Spaß / Sinn!

Sooooooo unvernünftig ist eine Weiterleitung also nicht ...

*Marx ist die Theorie, Murx ist die Praxis …

gefunden auf: http://blogex.schmidt-webdesign.net/*

Frohes neues Jahr!

Reyx

Kann ich nicht nachvollziehen.
Ich betreibe einen eigenen Webserver, wobei ich eine feste Adresse von DynDNS auf meine dynamische IP verweisen lasse. Der zugreifende Benutzer wird direkt zu meinem Websever geroutet. Der User greift auf http://irgendwas.dyndns/ zu und bekommt direkt die Inhalte meines Webservers gelieftert.

Und zum "Ausprobieren" ist die Debatte ohnehin hinfällig; da gibt es kein "gute Technik"/"böse Technik", welches man Besucher- oder Standardkonform halten muss. Ich denke hier bei einer Debatte meistens an eine produktiv eingesetzte, vielbesuchte Internetpräsenz

ronny

außerdem kann man immer noch redirect auf den host den der client erfragt hat machen, und somit alle cases abdecken

@rexy: dyndns kannste glatt vergessen. viel zu oft geht der scheiss garnicht und google listet dyndns.domains auch nicht. die brauchbaren dyndns-dienste musste löhnen!

@schmidt-webdesign.net: deine seite hat bei google trotz der umleitung und wechselnder ip sehr gutes ranking. wie aktualisirst du denn die statikpage nach einer trennung? und was hast du für nen provider weil deine seiten rel. schnell geladen werden?

Reyx

irgendwer schrieb:

@rexy: dyndns kannste glatt vergessen. viel zu oft geht der scheiss garnicht und google listet dyndns.domains auch nicht.

Das er "nicht gehen würde" kann ich aus eigener Erfahrung nicht nachvollziehen, aber gut möglich, dass dies des öfteren der Fall ist ...

irgendwer schrieb:

die brauchbaren dyndns-dienste musste löhnen!

Und das ist so schlimm, weil ... ?
Ich frage mich, wieso kaum ein Mensch bereit ist, für Leistung auch etwas zu blechen ...

geeky

Reyx schrieb:

I.d.R. wäre es viel Besucherfreundlicher, den erwarteten Inhalt einfach unter der erwarteten Adresse bereit zu stellen! Punkt.

Finde ich auch.

Allerdings gibt es dann mit einigen php-skripte Cookie-Probleme: Besucher besucht beispieldomain.de und dort wird ein cookie gesetzt. Später will der Besucher die Seite wieder besuchen, gibt aber diesmal beispiel-domain.de ein: Der Browser liefert das Cookie nicht an beispiel-domain.de, da beispiel-domain.de nicht beispieldomain.de ist.

Cookies treiben mich noch irgendwann in den Wahnsinn

(P.S.: /me hat bisher keine Probleme mit dyndns.org gehabt...)

Reyx

geeky schrieb:

Allerdings gibt es dann mit einigen php-skripte Cookie-Probleme: Besucher besucht beispieldomain.de und dort wird ein cookie gesetzt. Später will der Besucher die Seite wieder besuchen, gibt aber diesmal beispiel-domain.de ein: Der Browser liefert das Cookie nicht an beispiel-domain.de, da beispiel-domain.de nicht beispieldomain.de ist.

Naja, da kommt es dann halt auf den Inhalt an. Für die allermeisten Spielereien, für die Cookies benutzt werden, wären sie absolut überflüssig.

Mindestens 90% aller sinnvollen Einsätze von Cookies sind mit Loginformularen verbunden, so dass dann im Anschluss die Session-Daten mit einem User verbunden werden können (z.B. bei einem CMS oder Onlineshops etc. etc.). Und wer auf ein Loginformular verlinkt, der wird es auch noch fertig bringen, diese Verlinkung immer auf die gleiche URL zu setzen

Etwas komplizierter wird es z.B. bei Foren, wenn diese unter unterschiedlichen Domains erreichbar sind; wobei, es reicht ja schon, den URI einmal mit www. und einmal ohne zu schreiben! Da stellt sich mir aber die Frage, ob es denn wirklich ein Nachteil ist: Ich rufe eine Webseite, auch wenn sie zig Domains hat, meistens nur über eine dieser Domains auf! Ich gebe immer www.c-plusplus.net an, in 99% der Fälle nicht c-plusplus.net oder gar c-plusplus.info. Und wenn dann bei den restlichen 1% (die meisten nur Vertipper sind, wenn ich z.B. mal das www. vergesse) der Cookie nicht funzt, dann ist das auch nicht die Welt ...

Ich will mich nicht zum Maßstab der Dinge machen, aber ich denke kaum, dass es viele Leute gibt, die eine Webseite jeden Tag über eine andere der vier Domains, die sie vielleicht hat, anspricht

geeky schrieb:

Cookies treiben mich noch irgendwann in den Wahnsinn

Wie gesagt: Meistens, weil sie falsch verwendet werden