Technikwürze – Web Standards Podcast

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 ;)

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

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?

@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.

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

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

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

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 ().

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

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

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) ;-)

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.