mod_rewrite / Hilfe bei RewriteRules

[Gunther]

Hallo Selfgemeinde!

Egal wie lange und wie intensiv ich mich mit diesem Kapitel beschäftige, ich finde alleine keine 100%ig funktionierende Lösung. Deshalb wäre es sehr nett, wenn ihr mir bitte dabei helfen würdet - danke!

Ich möchte gerne, dass die .htaccess in meinem Root-Verzeichnis folgende Dinge per Rewrite erledigt:
-------------- Redirects --------------
1. Trailing Slashes sollen entfernt werden
2. mehrere mehrfach vorkommende Slashes sollen jeweils auf einen reduziert werden
3. irgendwelche Dateiendungen, bzw. generell einfach alles ab einem Punkt '.' in der URL soll entfernt werden
-------------- ohne Redirect --------------
4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

Zur Erläuterung:
Die Punkte 1-3 dienen in erster Linie dem "Komfort" des Users, sprich sollen u.a. Tippfehler durch manuelle Eingabe "ausbügeln".

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Generell soll natürlich auch vermieden werden, dass eine Resource unter mehr als einer URL erreichbar ist - Stichwort "Dublicate Content". Insbesondere im Root-Verzeichnis.

Eigentlich wäre mir auch am liebsten, dass man im Root-Verzeichnis "manuell" gar keine Datei aufrufen kann, wobei ich mir nicht ganz im Klaren darüber bin, ob das wirklich geht, bzw. sinnvoll ist? Zwar liegen eben fast alle anderen Files in separaten Directories, aber für die Bots bspw. gibt es natürlich eine robots.txt!

Und da ich ja weiß, dass wir hier bei SELFHTML sind, hier mein bisheriger "Entwurf" der
.htaccess:

DirectoryIndex start.php

<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . %1/%2 [R=301,L]

RewriteCond %{REQUEST_URI} ^/start.php$
RewriteRule . / [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^/$
RewriteCond %{REQUEST_URI} ^([^.]*). [OR]
RewriteCond %{REQUEST_URI} ^(.*)/$
RewriteRule ^(.*)$ %1 [R=301,L]

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*)$ /start.php/$1 [L,NE]
</IfModule>

Für eure Hilfe, Tipps, Anregungen und Vorschläge meinen besten Dank im Voraus!

Gruß Gunther

[hotti]

hi,

4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Wie, alle, *.html?

Hotti

[Gunther]

Hi,

4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Wie, alle, *.html?

ich verstehe deine Frage nicht ganz.
Ja, alle Requests sollen an_eine_Datei weitergeleitet werden, die dann die weitere Verarbeitung übernimmt. Natürlich ausgenommen solche, die auf real existierende Unterverzeichnisse zeigen, um bspw. Stylesheets und ähnliches anzufordern. Aber diese Dateien liegen wiegesagt alle in Unterverzeichnissen.

Gruß Gunther

[hotti]

Hi,

4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Wie, alle, *.html?
ich verstehe deine Frage nicht ganz.

Nunja, eine Beschränkung auf eine Dateierweiterung ist sinnvoll.

Ja, alle Requests sollen an_eine_Datei weitergeleitet werden, die dann die weitere Verarbeitung übernimmt. Natürlich ausgenommen solche, die auf real existierende Unterverzeichnisse zeigen, um bspw. Stylesheets und ähnliches anzufordern. Aber diese Dateien liegen wiegesagt alle in Unterverzeichnissen.

Letzeres löse ich nicht in der .htaccess sondern bereits in der Projektverwaltung. Meine Regel sieht so aus:

RewriteEngine on
RewriteRule ^.*.html$    /cgi-bin/show.cgi?html

Also eine Regel für *.html. Da mein Script show.cgi noch andere Dinge erledigen muss, gebe ich in den QUERY_STRING [1] die Info mit, dass es sich um Requests auf html-Dateien hadelt. Das Script schaut nun in eine Tabelle, ob es einen Eintrag für den REQUEST_URI [1] gibt; diese Tabelle wird aus meiner Projektverwaltung heraus erzeugt.

[1] CGI-Umgebungsvariablen

Hotti

[Gunther]

Hi,

4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Wie, alle, *.html?
ich verstehe deine Frage nicht ganz.

Nunja, eine Beschränkung auf eine Dateierweiterung ist sinnvoll.

Warum?
Ich halte Dateierweiterungen in URLs prinzipiell für_nicht_sinnvoll.

Ja, alle Requests sollen an_eine_Datei weitergeleitet werden, die dann die weitere Verarbeitung übernimmt. Natürlich ausgenommen solche, die auf real existierende Unterverzeichnisse zeigen, um bspw. Stylesheets und ähnliches anzufordern. Aber diese Dateien liegen wiegesagt alle in Unterverzeichnissen.

Letzeres löse ich nicht in der .htaccess sondern bereits in der Projektverwaltung. Meine Regel sieht so aus:

RewriteEngine on
RewriteRule ^.*.html$    /cgi-bin/show.cgi?html

Also eine Regel für *.html. Da mein Script show.cgi noch andere Dinge erledigen muss, gebe ich in den QUERY_STRING [1] die Info mit, dass es sich um Requests auf html-Dateien hadelt. Das Script schaut nun in eine Tabelle, ob es einen Eintrag für den REQUEST_URI [1] gibt; diese Tabelle wird aus meiner Projektverwaltung heraus erzeugt.

Das mag ja für dein Projekt auch alles so OK sein, nur kann ich das für meinen Fall nicht gebrauchen.

Mir geht es wie bereits erwähnt, u.a. um die folgenden Punkte:
Ich möchte nicht, dass bspw. ein simpler Tippfehler (also solche, die 'logisch' als solche erkennbar sind) wie ein doppelter (oder x-facher) Slash '/' zu einem 404er führt, wenn es ohne eine passende Resource gibt. Ebenfalls ganz wichtig ist eben auch, dass es jede Resource nur durch genau eine URL erreichbar ist.

Gruß Gunther

[Sven Rautenberg]

Moin!

Nunja, eine Beschränkung auf eine Dateierweiterung ist sinnvoll.
Warum?
Ich halte Dateierweiterungen in URLs prinzipiell für_nicht_sinnvoll.

Ich würde da aus diversen Gründen widersprechen wollen.

Erstens: Sie sind nunmal de facto da. Die Mehrheit der URLs enthält sie, jedermann hat sich dran gewöhnt - kann das aber elegant ignorieren, weil heutzutage kaum jemand URLs noch bis zum letzten Zeichen per Hand eingibt.

Zweitens: Es gibt zahlreiche URLs, die nur MIT Dateiendung funktionieren. robots.txt, favicon.ico, sitemap.xml, ... Diese Adressen sind in irgendwelchen Standards definiert worden, obwohl deren Autoren zum Zeitpunkt der Standardisierung das Wissen besaßen, dass Dateiendungen in der URL nicht NOTWENDIG sind.

Drittens: Dateiendungen in der URL geben dem Webserver eine relativ einfache Möglichkeit, der auszuliefernden Ressource einen passenden Content-Type zuzuordnen, ohne dass dafür weitergehende Magie (Dateiinhaltsanalyse) oder Skripteinfluß benötigt wird.

Viertens: Dateiendungen in der URL erlauben es auf Clientsystemen, die Ressourcen betriebssystemkompatibel abzuspeichern, so dass die Info über den Dateiinhalt nicht verloren geht. ".jpg" ist unter Windows, Linux und Mac OS aussagekräftig - unabhängig davon, ob das Betriebssystem in einer Datei-Metainformation noch weitere Informationen zum Dateityp, aufzurufenden Programmen etc. bereithält.

- Sven Rautenberg

[Gunther]

Moin Moin!

Nunja, eine Beschränkung auf eine Dateierweiterung ist sinnvoll.
Warum?
Ich halte Dateierweiterungen in URLs prinzipiell für_nicht_sinnvoll.

Ich würde da aus diversen Gründen widersprechen wollen.

Ja, völlig zu Recht!
Ich habe mich da auch falsch, bzw. nicht hinreichend genau und ausführlich genug ausgedrückt.

Was ich damit eigentlich zum Ausdruck bringen wollte ist, dass ich sie bei [1]für den User "relevanten"/ gedachten URLs, insbesondere bei "sprechenden" URLs für nicht sinnvoll erachte.

In allen anderen Fällen stimme ich dir voll und ganz zu!

Gruß Gunther

[1] Also wie u.a. im SELFHTML Weblog, wo sie auch nicht verwendet werden.

[suit]

Zweitens: Es gibt zahlreiche URLs, die nur MIT Dateiendung funktionieren. robots.txt, favicon.ico, sitemap.xml, ... Diese Adressen sind [...]

Du widersprichst dir - die URLs haben mit Dateiendungen nix zu tun.

Meine Ressource mit dem namen /sitemap.xml hat z.B. keine Datei "sitemap.xml" im Hintergrund - sie wird per mod_rewrite auf die index.php mit einer bestimmten ID umgeschrieben. - ebenso ginge das auch für z.B. robots.txt

[hotti]

Zweitens: Es gibt zahlreiche URLs, die nur MIT Dateiendung funktionieren. robots.txt, favicon.ico, sitemap.xml, ... Diese Adressen sind [...]

Du widersprichst dir - die URLs haben mit Dateiendungen nix zu tun.

Meine Ressource mit dem namen /sitemap.xml hat z.B. keine Datei "sitemap.xml" im Hintergrund - sie wird per mod_rewrite auf die index.php mit einer bestimmten ID umgeschrieben. - ebenso ginge das auch für z.B. robots.txt

Aber das was Du rausgibst, als Response ist doch auch ne Datei ;-)

Nur mal so angmerkt.

Hotti

[suit]

Aber das was Du rausgibst, als Response ist doch auch ne Datei ;-)

Nein, ich geb' eine HTTP-Antwort raus - mit HTTP-Header und Content. Das ist keine physisch vorhandene Datei. Der Browser speichert den Content dann idR. als Datei in seinem Cache.

[hotti]

Aber das was Du rausgibst, als Response ist doch auch ne Datei ;-)

Nein, ich geb' eine HTTP-Antwort raus - mit HTTP-Header und Content. Das ist keine physisch vorhandene Datei. Der Browser speichert den Content dann idR. als Datei in seinem Cache.

Ehe wir uns weiter in die Wolle kriegen ;-)

Also eine Datei muss nicht immer auch ne Datei im Dateisystem sein. Klar, ich weiß schon, was Du meinst und ich meine, dass auch eine Response abstrakt gesehen eine Datei ist.

Horst Dat-ei

[Der Martin]

Hallo,

Ich halte Dateierweiterungen in URLs prinzipiell für_nicht_sinnvoll.
Ich würde da aus diversen Gründen widersprechen wollen.

ich widerspreche deinem Standpunkt und schließe mich damit im Wesentlichen suit an.

Erstens: Sie sind nunmal de facto da. Die Mehrheit der URLs enthält sie, jedermann hat sich dran gewöhnt - kann das aber elegant ignorieren, weil heutzutage kaum jemand URLs noch bis zum letzten Zeichen per Hand eingibt.

Sondern? Wie gibst du eine URL ein, die du in einem Zeitungsartikel, in einer Einblendung im Fernsehwerbespot, auf einem Plakat, einer Produktverpackung findest?

Zweitens: Es gibt zahlreiche URLs, die nur MIT Dateiendung funktionieren. robots.txt, favicon.ico, sitemap.xml, ... Diese Adressen sind in irgendwelchen Standards definiert worden, obwohl deren Autoren zum Zeitpunkt der Standardisierung das Wissen besaßen, dass Dateiendungen in der URL nicht NOTWENDIG sind.

Ja. Das sind aber mehr oder weniger beliebig gewählte Namen, die eine Extension haben, um die Struktur des Inhalts zu beschreiben. Trotzdem sind es nur URLs, und damit HTTP-Ressourcen, die nicht unbedingt mit einer Datei korrelieren müssen.

Drittens: Dateiendungen in der URL geben dem Webserver eine relativ einfache Möglichkeit, der auszuliefernden Ressource einen passenden Content-Type zuzuordnen, ohne dass dafür weitergehende Magie (Dateiinhaltsanalyse) oder Skripteinfluß benötigt wird.

Auch hier reden wir aber konkret von Dateiendungen, also von Dateien, die im Filesystem des Webservers existieren. Diese Bezeichnungen 1:1 auf die URLs abzubilden, ist zwar naheliegend, aber keineswegs selbstverständlich.

Viertens: Dateiendungen in der URL erlauben es auf Clientsystemen, die Ressourcen betriebssystemkompatibel abzuspeichern, so dass die Info über den Dateiinhalt nicht verloren geht.

Nein, Clients sollten sich eigentlich am MIME-Typ orientieren und ihre Info daraus ableiten (wenn sie nicht gerade Internet Explorer heißen). Eine Ressource, die als http://example.org/fusselwurst.txt mit dem MIME-Typ image/png ausgeliefert wird, müsste ein Client immer noch als fusselwurst.txt.png speichern (oder sogar fusselwurst.png).

".jpg" ist unter Windows, Linux und Mac OS aussagekräftig - unabhängig davon, ob das Betriebssystem in einer Datei-Metainformation noch weitere Informationen zum Dateityp, aufzurufenden Programmen etc. bereithält.

Ja, dennoch mixt du hier die Kontexte "URL" und "Datei" nach Belieben zusammen.

So long,
 Martin

[hotti]

hi,

Nunja, eine Beschränkung auf eine Dateierweiterung ist sinnvoll.
Warum?
Ich halte Dateierweiterungen in URLs prinzipiell für_nicht_sinnvoll.

Ich würde da aus diversen Gründen widersprechen wollen.

Klar: Ich finde Dateierweiterungen grundsätzlich gut. Damit kann ich nämlich schon in meiner Projektverwaltung das Zeugs auseinanderhalten, also otto.html ist ne html-Datei und otto.jpg ist ein Bild was da mit img src eingefügt wird. Chaotisch wäre es, wenn "otto", "erwin", "anne" HTMl-Dateien wären und die Bilder, die da reinsollen haben Namen wie "elli", "erna", "wilhelm". Bei 200 Seiten und 100 Bildern isses ziemlich schwierig, da noch durchzublicken. Feilich kann ich da alles umschießen auf eine eigene Nomenglatur, beispielsweise kriegen alle HTML-Dateien ein 'hatemelli' vorne oder hintendrangepappt statt .html. Ich könnte für Aldi anderen MIME-Types totschicke Namensvereinbarungen aushecken und das ganze Chaos was sich daraus ergibt 1:1 an meine Besucher weiterreichen. Eine URL like erwin_99_31 ist das was woanders "index.html" heißt, ich baue mir rewrite_rules für alle verschiedenen Content-Types, die ich hab und lege fest, dass alle Dateien mit weiblichen Namen animierte GIFs sind. Aber dann kommt der Super GAU: Ich leite per rewrite alles um auf otto_00_65 was bei mir ein CGI-Script ist. Dass es innerhalb der CGI-Schnittstelle ausgeführt wird, hab ich nach stundenlangen Telefonaten mit meinem ISP hinbekommen, naja, einen 20er musste ich extra berappen aber was solls. Nun jedoch bin ich am Ende, mein Webserver hat sich gerade festgefahren, weil das Rewriting aller ressourcen auf otto_00_65 irgendwie nicht aufhören will.

Hotti

[suit]

Bei 200 Seiten und 100 Bildern isses ziemlich schwierig, da noch durchzublicken.

Das hängt vom Dateisystem und dem verwendeten Dateimanager ab

Windows zeigt das in der Detailansicht seit jeher so an:

Name    Typ
foo.jpg Graphics Interchange Format Image
bar.jpg Graphics Interchange Format Image
baz.swf Shockwave-Flash Movie
qux.png Portable Network Graphics Image

Die Dateiendung ist da schön und gut - es ist aber nicht mehr wirklich notwendig, dass sie an der Datei selbst hängt.

[Der Martin]

Hallo,

Windows zeigt das in der Detailansicht seit jeher so an:

Name    Typ
foo.jpg Graphics Interchange Format Image
bar.jpg Graphics Interchange Format Image

verwechselt dein Windows hier JPEG und GIF?

Die Dateiendung ist da schön und gut - es ist aber nicht mehr wirklich notwendig, dass sie an der Datei selbst hängt.

Doch, für Windows schon. Für Windows ist nämlich die Dateiendung das einzige Merkmal, an dem der Typ identifiziert wird (wohlgemerkt: bei Dateien, nicht HTTP-Ressourcen).

So long,
 Martin

[suit]

verwechselt dein Windows hier JPEG und GIF?

Offenbar ja - im Header der Dateien steht eindeutig JFIF und die Endung besagt auch eindeutig .jpg

Andere files mit .jpeg als Endung werden korrekt als JPEG-Image erkannt :)

Doch, für Windows schon. Für Windows ist nämlich die Dateiendung das einzige Merkmal, an dem der Typ identifiziert wird (wohlgemerkt: bei Dateien, nicht HTTP-Ressourcen).

Für meins Windows XP hier offenbar nicht :D

[hotti]

Bei 200 Seiten und 100 Bildern isses ziemlich schwierig, da noch durchzublicken.

Das hängt vom Dateisystem und dem verwendeten Dateimanager ab

Windows zeigt das in der Detailansicht seit jeher so an:

Lenk hier mal nicht ab Du ;-)

Ich denke in Richtung Projektverwaltung und die dürfte ohne Dateierweiterungen in einem Chaos enden.

Horst Hasel.huhn (Content-Type: x-save/as_ei)

[suit]

Ich denke in Richtung Projektverwaltung und die dürfte ohne Dateierweiterungen in einem Chaos enden.

Gewöhnungssache.

Wenn alle Dateien endungslos wären und der Filemanager den MIME-Type korrekt anzeigen würde, wäre das ok.

[hotti]

hi,

Nunja, eine Beschränkung auf eine Dateierweiterung ist sinnvoll.
Warum?

Bissl Ordnung muss schon sein.

Ich halte Dateierweiterungen in URLs prinzipiell für_nicht_sinnvoll.

Dann ist ja die von Dir angestrebte Korrektur auch überflüssig.

Viele Grüße,
Horst Haselhuhn

[Sven Rautenberg]

Moin!

Ich möchte gerne, dass die .htaccess in meinem Root-Verzeichnis folgende Dinge per Rewrite erledigt:
-------------- Redirects --------------

1. Trailing Slashes sollen entfernt werden
2. mehrere mehrfach vorkommende Slashes sollen jeweils auf einen reduziert werden
3. irgendwelche Dateiendungen, bzw. generell einfach alles ab einem Punkt '.' in der URL soll entfernt werden

Das sind alles recht komplexe Operationen, die aber ja nicht als Default vorkommen - weil du deine URLs ja nicht so gestaltest, dass sie deinen eigenen Regeln widersprechen.

Deshalb würde ich diesen ganzen Schmodder aus dem Rewriting raushalten und explizit in den Code tun, welcher...

-------------- ohne Redirect --------------
4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

alle deine Requests ohnehin analysieren muss, und der dann ggf. anstelle einer geforderten Seite einen Redirect ausspuckt.

Ist zwar im Endeffekt unnütze doppelte Arbeit, weil der Redirect natürlich nahezu instant wieder genau dasselbe Skript ausführt, was aber ja blöderweise erneut eingelesen, geparst und ausgeführt werden muss, aber was tut man nicht alles für die URL-Reinheit...

...beispielsweise könnte man anstelle eines Redirects auch mit einem 404 antworten - schließlich sind deine eigenen URLs ja alle existent und führen zu Seiten - und wenn sich irgendwer URLs ausdenkt und sich vertippt, dann sollte er das auch feststellen. URLs tippt man heutzutage doch sowieso nur noch ein, wenn sie kurz sind und nicht in der History stehen. Ansonsten klickt man auf Googles Suchergebnisse oder die Seitennavigation.

Und für spezielle, "nette" URLs, die sich für Sonderverwendung in Radiowerbung, Papierwerbung oder Real-Welt-Werbung eignen soll, baut man explizite Redirects auf die zugehörige korrekte URL, sofern das unbedingt sein muss, weil es sonst die Site-Struktur zerhaut.

Zur Erläuterung:
Die Punkte 1-3 dienen in erster Linie dem "Komfort" des Users, sprich sollen u.a. Tippfehler durch manuelle Eingabe "ausbügeln".

Es gibt ja das Modul "mod_speling", welches dann anspringt, wenn die tatsächliche URL nicht gefunden wird, indem der Server dann nach ähnlichen Dateinamen sucht - GroßKleinSchreibung auswechselt, ggf. Zeichen weglässt, etc.

Hat zur Folge, dass man als Ersteller von Webseiten nicht auf den ersten Blick sieht, wo man Tippfehler gemacht hat, die einen dann aber böse beißen, sobald der Server mal gewechselt wird, der kein mod_speling hat. Und so wahnsinnig performant ist das auch nicht wirklich.

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Generell soll natürlich auch vermieden werden, dass eine Resource unter mehr als einer URL erreichbar ist - Stichwort "Dublicate Content". Insbesondere im Root-Verzeichnis.

Du überbewertest Googles Rating solcher Ereignisse.

Sowas ergibt sich gar nicht erst, weil du ja ein vernünftiges URL-Schema erdacht hast, welches jede URL eindeutig zu einem Content mappt - was wiederum das Kriterium ist, ob die URL existiert.

Eigentlich wäre mir auch am liebsten, dass man im Root-Verzeichnis "manuell" gar keine Datei aufrufen kann, wobei ich mir nicht ganz im Klaren darüber bin, ob das wirklich geht, bzw. sinnvoll ist? Zwar liegen eben fast alle anderen Files in separaten Directories, aber für die Bots bspw. gibt es natürlich eine robots.txt!

Glaube nicht, dass das sinnvoll ist. Dass auf dem Server keine beliebige Unordnung entsteht, ist die Aufgabe des Webmasters, mutmaßlich also deine. Und wie Google zum Inhalt von "robots.txt" kommt, ist vollkommen dir überlassen. Wenn du es toll findest, für diesen garantiert auftretenden Fall (übrigens genauso garantiert auftretend, wie Requests nach "favicon.ico") in dein PHP-Skript eine Sonderbehandlung reinzucoden, inklusive passendem Handling des Content-Typs, darfst du gerne sämtliche URLs vollkommen von der Existenz realer Dateien loslösen.

Ich denke nur, dass das nicht wirklich zielführend ist, zumal der Webserver sowas deutlich effizienter ausliefern kann - ohne Skriptaufruf.

Und da ich ja weiß, dass wir hier bei SELFHTML sind, hier mein bisheriger "Entwurf" der .htaccess:

Boah, da erkenne ich auf den ersten Blick absolut gar nichts, was da mit der URL angestellt wird. Und das ist schon mal ein schlechtes Zeichen, denn diese Frage stellt sich irgendwann im Laufe der Lebensdauer des Projekts. Und da wäre es dann deutlich angenehmer, wenn die diversen Umwandlungen der URL sich in dokumentiertem PHP-Code abspielten, anstelle in eher undokumentierten RewriteRules und RewriteConds.

- Sven Rautenberg

[Gunther]

Moin Sven!

Vielen Dank für deine gewohnt hilfreich und fundierte Antwort.

Das sind alles recht komplexe Operationen, die aber ja nicht als Default vorkommen - weil du deine URLs ja nicht so gestaltest, dass sie deinen eigenen Regeln widersprechen.

Deshalb würde ich diesen ganzen Schmodder aus dem Rewriting raushalten und explizit in den Code tun, welcher...

-------------- ohne Redirect --------------
4. alle Requests sollen an eine Datei, z.B. start.php weitergeleitet werden

alle deine Requests ohnehin analysieren muss, und der dann ggf. anstelle einer geforderten Seite einen Redirect ausspuckt.

Ist zwar im Endeffekt unnütze doppelte Arbeit, weil der Redirect natürlich nahezu instant wieder genau dasselbe Skript ausführt, was aber ja blöderweise erneut eingelesen, geparst und ausgeführt werden muss, aber was tut man nicht alles für die URL-Reinheit...

Das habe ich mir (natürlich) auch schon überlegt gehabt, weil es für mich sicherlich auch deutlich einfacher zu handhaben wäre, als das "Gewurschtel" mit mod_rewrite. Nur der Punkt mit "unnütze doppelte Arbeit ..." hat mich bisher davon abgehalten. Allerdings hast du natürlich auch mit "weil du ja ein vernünftiges URL-Schema erdacht hast" Recht, sodass dieser Fall ja nur dann auftritt, wenn ein User nicht "auf Googles Suchergebnisse" klickt.

...beispielsweise könnte man anstelle eines Redirects auch mit einem 404 antworten - schließlich sind deine eigenen URLs ja alle existent und führen zu Seiten - und wenn sich irgendwer URLs ausdenkt und sich vertippt, dann sollte er das auch feststellen. URLs tippt man heutzutage doch sowieso nur noch ein, wenn sie kurz sind und nicht in der History stehen. Ansonsten klickt man auf Googles Suchergebnisse oder die Seitennavigation.

Das ist eben so eine zweischneidige Sache, wobei es imho jeweils gute Argumente für jede der beiden Varianten gibt.

Punkt 4 ist letztlich der eigentlich wichtigste, da sämtliche Requests über meine Startdatei laufen sollen.

Generell soll natürlich auch vermieden werden, dass eine Resource unter mehr als einer URL erreichbar ist - Stichwort "Dublicate Content". Insbesondere im Root-Verzeichnis.

Du überbewertest Googles Rating solcher Ereignisse.

Hmmm ..., mag sein. Trotzdem bin ich ein Freund von URL normalization - nicht_nur_wegen Google.

Sowas ergibt sich gar nicht erst, weil du ja ein vernünftiges URL-Schema erdacht hast, welches jede URL eindeutig zu einem Content mappt - was wiederum das Kriterium ist, ob die URL existiert.

Diese "Problematik" besteht ja auch in allererster Linie beim Root-Verzeichnis und Directories aufgrund serverseitiger "Automatismen" im Bezug auf Index-Dateien.

Eigentlich wäre mir auch am liebsten, dass man im Root-Verzeichnis "manuell" gar keine Datei aufrufen kann, ...

Glaube nicht, dass das sinnvoll ist.

Ja, nach nochmaliger Überlegung glaube ich das auch nicht.

Und da ich ja weiß, dass wir hier bei SELFHTML sind, hier mein bisheriger "Entwurf" der .htaccess:

Boah, da erkenne ich auf den ersten Blick absolut gar nichts, was da mit der URL angestellt wird. Und da wäre es dann deutlich angenehmer, wenn die diversen Umwandlungen der URL sich in dokumentiertem PHP-Code abspielten, anstelle in eher undokumentierten RewriteRules und RewriteConds.

Ja, ja - ist ja schon gut. ;-)
Sorry, dass ich die Dokumentation bei den paar Rules vergessen habe - ich dachte halt, Profis wie du erkennen das auch so auf den ersten Blick.

FAZIT:
Ich werde wohl meine RewriteRules in der htaccess auf ein Minimum beschränken und den Rest lieber gleich in meinem PHP-Script machen und dann ggf. per Location-Header das Rewriting/ Redirecting vornehmen.

Also besten Dank nochmal - oft hilft es halt schon, wenn man mal eine andere (fachkundige) Meinung zu den eigenen Ideen liest.

Gruß Gunther

[Sven Rautenberg]

Moin!

Ist zwar im Endeffekt unnütze doppelte Arbeit, weil der Redirect natürlich nahezu instant wieder genau dasselbe Skript ausführt, was aber ja blöderweise erneut eingelesen, geparst und ausgeführt werden muss, aber was tut man nicht alles für die URL-Reinheit...
Das habe ich mir (natürlich) auch schon überlegt gehabt, weil es für mich sicherlich auch deutlich einfacher zu handhaben wäre, als das "Gewurschtel" mit mod_rewrite. Nur der Punkt mit "unnütze doppelte Arbeit ..." hat mich bisher davon abgehalten. Allerdings hast du natürlich auch mit "weil du ja ein vernünftiges URL-Schema erdacht hast" Recht, sodass dieser Fall ja nur dann auftritt, wenn ein User nicht "auf Googles Suchergebnisse" klickt.

Die unnütze doppelte Arbeit tritt hingegen immer auf, wenn du deine Rewrite-Rules abarbeiten lässt. Die werden bei jedem Request aktiv - und zwar komplett, weil du ja erstmal auf Redirects prüfen musst. Und auch bei allen Requests nach sonstigen Ressourcen, Bildern, CSS, JS,...

- Sven Rautenberg

[ChrisB]

Hi,

Generell soll natürlich auch vermieden werden, dass eine Resource unter mehr als einer URL erreichbar ist - Stichwort "Dublicate Content". Insbesondere im Root-Verzeichnis.

Du überbewertest Googles Rating solcher Ereignisse.
Hmmm ..., mag sein.

Und das neue "Feature" rel="canonical" schafft diesbezüglich auch erst mal Abhilfe.

Trotzdem bin ich ein Freund von URL normalization - nicht_nur_wegen Google.

Ich eigentlich auch.
Aber in dem Bereich gilt - vieles kann, weniges *muss*.
Das ist mehr eigener Ordnungsfanatismus, als aus der Realität entspringende Notwendigkeit.

MfG ChrisB

[Gunther]

Hi Chris!

Generell soll natürlich auch vermieden werden, dass eine Resource unter mehr als einer URL erreichbar ist - Stichwort "Dublicate Content". Insbesondere im Root-Verzeichnis.

Du überbewertest Googles Rating solcher Ereignisse.
Hmmm ..., mag sein.

Und das neue "Feature" rel="canonical" schafft diesbezüglich auch erst mal Abhilfe.

Ha, wieder etwas Neues erfahren. Das war mir bis dato gänzlich unbekannt - besten Dank!

Jetzt zu meiner neuen Frage:
Wie sehen die Meinungen bezüglich folgender Strategie aus?

• Macht es aus eurer Sicht Sinn, den Bots, die sich offen als solche zu erkennen geben (bspw. per User-Agent), bspw. bei Links mit Query Strings, einen anderen Inhalt zu liefern, als den normalen Usern?
• Oder ihnen zwar den "normalen" Content, aber mit anderem HTTP Header (bspw. 404) auszuliefern?

Angeregt wurden meine Überlegungen übrigens durch den hier im Thread vorgebrachten Vorschlag, Such(ergebnis)seiten generell mit einem 404er auszuliefern.

Ich würde mich freuen, wenn sich hier nochmal eine angeregte Diskussion über das Thema URL-Design entwickeln würde. Ist doch u.a. mit eines der wichtigsten Thema, und vorallem eines, welches sich im Nachhinein nur sehr schwierig ändern lässt (zumindest nicht ohne großen Aufwand).

Gruß Gunther

[ChrisB]

Hi,

• Macht es aus eurer Sicht Sinn, den Bots, die sich offen als solche zu erkennen geben (bspw. per User-Agent), bspw. bei Links mit Query Strings, einen anderen Inhalt zu liefern, als den normalen Usern?

Nein, überhaupt nicht.
Wenn die Suchmaschinen merken, dass sie andere Inhalte vorgesetzt bekommen, als der normale Surfer, dann strafen sie das idR. ab.

• Oder ihnen zwar den "normalen" Content, aber mit anderem HTTP Header (bspw. 404) auszuliefern?

Nein, auch unsinnig.
Der HTTP-Statuscode 404 ist für die SuMa das entscheidende, der Inhalt dieses Dokuments interessiert sie kaum; 404 ist dazu *da*, ihr zu sagen, dass der gewünschte Inhalt nicht gefunden würde - also hat sie keinen Grund, dem damit ausgelieferten Dokumentinhalt irgendeine Bedeutung beizumessen.

Angeregt wurden meine Überlegungen übrigens durch den hier im Thread vorgebrachten Vorschlag, Such(ergebnis)seiten generell mit einem 404er auszuliefern.

Halte ich nicht viel von.

Eine "normale", vom Benutzer durchgeführte Suche (über explizit auf der Seite bereitgestellte Funktionalität), kann mein Server auf jeden Fall bedienen. Wenn diese keine Ergebnisse liefert, ist das zwar Pech für den Suchenden - aber für mich kein Fall von 404.

Anders sieht das aus, wenn man erst mal "sämtliche" Benutzereingaben in Form von URLs akzeptiert, und dann versucht, bei nicht auffindbaren Inhalten auf das nächstbeste zu verweisen - dann kann man in der 404-Antwort gerne auch "Hamm ja nich, aber meinten sie vielleicht eines der folgenden Dokumente: [Auflistung]" mit ausgeben.
Das wäre für mich eine "implizte" Suche, eine, die vom Benutzer nicht wirklich als solche beabsichtigt war - aber zu der ich ihm netterweise trotzdem ein paar (Alternativ-)Vorschläge unterbreite, um seine Trauer darüber, dass ich das eigentlich angeforderte nicht bieten kann, zu mindern.

MfG ChrisB

[Gunther]

Hi,

boah, ich werd' alt glaub' ich! Also erstmal eine Korrektur:
Die Anmerkung

Angeregt wurden meine Überlegungen übrigens durch den hier im Thread vorgebrachten Vorschlag, Such(ergebnis)seiten generell mit einem 404er auszuliefern.

bezog sich nicht auf diesen Thread hier, sondern auf den etwas älteren hier im Archiv.

• Macht es aus eurer Sicht Sinn, den Bots, die sich offen als solche zu erkennen geben (bspw. per User-Agent), bspw. bei Links mit Query Strings, einen anderen Inhalt zu liefern, als den normalen Usern?

Nein, überhaupt nicht.
Wenn die Suchmaschinen merken, dass sie andere Inhalte vorgesetzt bekommen, als der normale Surfer, dann strafen sie das idR. ab.

Ja, so ist mir das auch bekannt und fällt meines Wissens nach unter den Begriff "cloaking".
Google selber sagt ja u.a.:"Verhindern Sie mithilfe der Datei "robots.txt" das Crawlen von Suchergebnisseiten oder anderen automatisch erstellten Seiten, die keinen großen Wert für Besucher haben, die über eine Suchmaschine auf Ihre Website geleitet wurden."
(siehe: Richtlinien für Webmaster - Technische Richtlinien

• Oder ihnen zwar den "normalen" Content, aber mit anderem HTTP Header (bspw. 404) auszuliefern?

Nein, auch unsinnig.
Der HTTP-Statuscode 404 ist für die SuMa das entscheidende, der Inhalt dieses Dokuments interessiert sie kaum; 404 ist dazu *da*, ihr zu sagen, dass der gewünschte Inhalt nicht gefunden würde - also hat sie keinen Grund, dem damit ausgelieferten Dokumentinhalt irgendeine Bedeutung beizumessen.

Angeregt wurden meine Überlegungen übrigens durch den hier im Thread vorgebrachten Vorschlag, Such(ergebnis)seiten generell mit einem 404er auszuliefern.

Halte ich nicht viel von.

Zu der Ansicht tendiere ich auch eher.

Eine "normale", vom Benutzer durchgeführte Suche (über explizit auf der Seite bereitgestellte Funktionalität), kann mein Server auf jeden Fall bedienen. Wenn diese keine Ergebnisse liefert, ist das zwar Pech für den Suchenden - aber für mich kein Fall von 404.

Ja eben. Das ist für mich auch einer der Hauptgründe, das nicht so zu machen.

Anders sieht das aus, wenn man erst mal "sämtliche" Benutzereingaben in Form von URLs akzeptiert, und dann versucht, bei nicht auffindbaren Inhalten auf das nächstbeste zu verweisen - dann kann man in der 404-Antwort gerne auch "Hamm ja nich, aber meinten sie vielleicht eines der folgenden Dokumente: [Auflistung]" mit ausgeben.

Ja, weil dann ja auch eine konkret angeforderte Resource definitiv nicht verfügbar ist.

Jetzt frage ich mich allerdings nur noch, wie ich die braven Bots (also jene, die sich an die robots.txt halten), von allen möglichen Suchergebnisseiten fernhalten soll? Und außerdem ist diese Methode doch spätestens dann zum Scheitern verurteilt, wenn irgendwo im Web entsprechende Links auftauchen, auf die sich die Bots stürzen (auch der von Google)!?

Gruß Gunther

[ChrisB]

Hi,

Anders sieht das aus, wenn man erst mal "sämtliche" Benutzereingaben in Form von URLs akzeptiert, und dann versucht, bei nicht auffindbaren Inhalten auf das nächstbeste zu verweisen - dann kann man in der 404-Antwort gerne auch "Hamm ja nich, aber meinten sie vielleicht eines der folgenden Dokumente: [Auflistung]" mit ausgeben.
Ja, weil dann ja auch eine konkret angeforderte Resource definitiv nicht verfügbar ist.

Jetzt frage ich mich allerdings nur noch, wie ich die braven Bots (also jene, die sich an die robots.txt halten), von allen möglichen Suchergebnisseiten fernhalten soll?

Du hältst sie, was oben beschriebenes Szenario angeht - 404-Antwortdokument, das Alternativvorschläge enthält - dadurch davon fern, dies als für den Allgemeinsurfer relevanten Inhalt zu betrachten, dass du das ganze mit dem HTTP-Statuscode 404 auslieferst.
404 interpretiert auch ein durchschnittsinteligenter SuMa-Bot als das, was die HTTP-Spezifikation darunter versteht: Der Inhalt, der angefordert wurde, steht unter dieser Adresse definitiv nicht zur Verfügung. Damit ist das, was Google in seinen Richtlinien von dir will, erfüllt - du hast der Suchmaschine mitgeteilt, dass der Inhalt dieser

automatisch erstellten Seite[n], die keinen großen Wert für Besucher [hat], die über eine Suchmaschine auf Ihre Website geleitet wurden

genau so zu bewerten ist.

Und außerdem ist diese Methode doch spätestens dann zum Scheitern verurteilt, wenn irgendwo im Web entsprechende Links auftauchen, auf die sich die Bots stürzen (auch der von Google)!?

Wo Links auftauchen, ist egal - dein Server ist der, der Google gegenüber bei einer Anfrage nach einer solchen Adresse darüber "Rechenschaft ablegt", ob es unter dieser relevanten Inhalt gibt oder nicht.
Wenn nicht, dann sagst du einfach und ehrlich Nein - HTTP-Statuscode 404.

MfG ChrisB

[Gunther]

Hi,

Wo Links auftauchen, ist egal - dein Server ist der, der Google gegenüber bei einer Anfrage nach einer solchen Adresse darüber "Rechenschaft ablegt", ob es unter dieser relevanten Inhalt gibt oder nicht.
Wenn nicht, dann sagst du einfach und ehrlich Nein - HTTP-Statuscode 404.

OK, das habe ich jetzt soweit verstanden (und kriege es hoffentlich auch so umgesetzt) ;-). Dafür schonmal besten Dank.

Jetzt stehe ich noch vor einer weiteren Entscheidung, wo es für beide Varianten (wie immer) Pros & Cons gibt. Es wäre nett, wenn ihr mir hierzu auch nochmal bitte eure Meinung mitteilen würdet - danke!

Und zwar geht es um die Frage, ob ich in meinen "sprechenden URLs" auch Großschreibung verwenden soll, oder nicht?

Der wesentlichste Vorteil liegt eigentlich in einer noch besseren Lesbarkeit der Links.

Intern würde ich es so handhaben, dass es egal ist, wie es geschrieben ist, d.h. solange der Text unabhängig von Klein- oder Großschreibung matched, wird die Seite gefunden und ggf. (wegen der Kanonizität) auf die entsprechende Schreibweise redirected.

Gibt es noch andere Pros & Cons?
Wie würdet ihr es machen?

Gruß Gunther

[ChrisB]

Hi,

Und zwar geht es um die Frage, ob ich in meinen "sprechenden URLs" auch Großschreibung verwenden soll, oder nicht?

Der wesentlichste Vorteil liegt eigentlich in einer noch besseren Lesbarkeit der Links.

Sehe ich auch so.

Die Richtlinie, konsequent Kleinschreibung zu verwenden, stammt noch aus den Zeiten, als die unterschiedliche Handhabung durch die Dateisysteme von Windows und *nix maßgeblich war, weil URLs i.d.R. direkt auf's Dateisystem gematched wurden.

Jetzt, wo aber "dynamische" Inhalte in der Form, dass sie meist gar keine direkten physischen Entsprechungen im Dateisystem mehr haben, eher der Normalfall als die Regel sind, halte ich das nicht mehr für unbedingt angebracht.

Bspw. ist "USA" im Pfadbestandteil eines URLs für mich viel direkter zu erfassen, als "usa".

Auch in Punkto "Sonderzeichen" kann man da die Einstellung in baldiger Zukunft mal dem aktuellen Stand anpassen - wenn auch der IE mal nachzieht. Meine Gedanken dazu legte ich letztlich schon mal dar. Dass "Umlautdomains" möglich sind, bei denen auch ein ä im Domainpart in der Adresszeile korrekt dargestellt wird, ich statt eines solchen im Path- oder Query-String-Bestandteil des URL aber immer noch ein ae dafür schreiben soll, ist nicht mehr state-of-the-art.

Intern würde ich es so handhaben, dass es egal ist, wie es geschrieben ist, d.h. solange der Text unabhängig von Klein- oder Großschreibung matched, wird die Seite gefunden und ggf. (wegen der Kanonizität) auf die entsprechende Schreibweise redirected.

So werde ich das künftig auch halten.

Wenn die Daten nicht über allzu aufwegige Queries ermittelt werden, dann prüfe ich nicht vorher extra die Schreibweise explizit hinsichtlich korrekter Gross-/Kleinschreibung - sondern lasse mir beim Auslesen von der Datenbank einen Boole'schen Wert mit ermitteln, der angibt, ob die Schreibweise diesbezüglich korrekt war. Wenn ja, dann habe ich direkt meine Daten zum anzeigen; wenn nein, dann leite ich noch mal um.
Da der überwiegende Teil der Anfragen aus Links herrührt, die ich unter Kontrolle habe, und deshalb die Wahrscheinlichkeit einer zwar von den Buchstaben her richtigen, nur bzgl. des Cases falschen Anfrage "durch eintippen aus dem Gedächtnis" o.ä. gering ist, erscheint mir das die günstigere Vorgehensweise.

MfG ChrisB

[Gunther]

Hi,

vielen Dank für deine Antwort. Es erfreut mich ja immer, wenn ich als Laie eine Idee/ ein Konzept habe, welches die Zustimmung eines Experten findet. :-)

Von daher, nachdem dieser Teil soweit klar ist vom Grundsatz her, hätte ich noch ein paar (speziellere) Fragen dazu.

Auch in Punkto "Sonderzeichen" kann man da die Einstellung in baldiger Zukunft mal dem aktuellen Stand anpassen - wenn auch der IE mal nachzieht. Meine Gedanken dazu legte ich letztlich schon mal dar. Dass "Umlautdomains" möglich sind, bei denen auch ein ä im Domainpart in der Adresszeile korrekt dargestellt wird, ich statt eines solchen im Path- oder Query-String-Bestandteil des URL aber immer noch ein ae dafür schreiben soll, ist nicht mehr state-of-the-art.

Den verlinkten Beitrag, sowie dedlfixs Artikel "Kontextwechsel" habe ich mir jetzt schon zigfach durchgelesen, bin aber immer noch nicht schlau, bzw. mir der Sache sicher (Frage folgt weiter unten).

Intern würde ich es so handhaben, dass es egal ist, wie es geschrieben ist, d.h. solange der Text unabhängig von Klein- oder Großschreibung matched, wird die Seite gefunden und ggf. (wegen der Kanonizität) auf die entsprechende Schreibweise redirected.

So werde ich das künftig auch halten.

Wenn die Daten nicht über allzu aufwegige Queries ermittelt werden, dann prüfe ich nicht vorher extra die Schreibweise explizit hinsichtlich korrekter Gross-/Kleinschreibung - sondern lasse mir beim Auslesen von der Datenbank einen Boole'schen Wert mit ermitteln, der angibt, ob die Schreibweise diesbezüglich korrekt war. Wenn ja, dann habe ich direkt meine Daten zum anzeigen; wenn nein, dann leite ich noch mal um.

Ja, so ähnlich zumindest will ich es auch machen. Ich prüfe zuerst auf "Kriterien", die ich automatisch korrigieren will (trailing slash etc.) um ggf. direkt per 301 zu redirecten. Danach prüfe ich, ob die angegebene URL existiert. Falls nicht, binde ich eine weitere Prüfung ein, die ggf. "errät" welche URL gemeint war und diese (ggf. auch mehrere) dann vorschlägt. Diese Seite liefere ich dann mit einem 404er aus.

Da ich nicht unbedingt in der Lage bin, alle Eventualitäten im Vorfeld schon hinreichend zu berücksichtigen, gibt es da noch einige Punkte, wo ich nicht genau weiß, wie ich damit verfahren soll.

Meine bisherige Planung bezüglich des URL-Designs sieht eigentlich recht simpel aus. Normale Seiten (also überwiegend die reinen Artikel-Seiten) sind direkt über eine "sprechende" URL auf dem Root-Level erreichbar.
Also bspw.: http://example.com/Mein-neuester-Artikel

Ferner wollte ich das Media Wiki Namespace System übernehmen. Also bspw. soll eine Übersichtsseite mit allen Artikeln zu einem "Tag" dann so erreichbar sein:
http://example.com/Tag:CSS

Etwas unsicherer bin ich mir schon bei der Suche. Ich dachte bisher an etwas wie:
Suchseite: http://example.com/Search:
Ergebnisseite: http://example.com/Search(result?):CSS+HTML+Usability

Wie man bereits jetzt schon feststellen kann, schwanke ich auch noch zwischen englischen und deutschen Bezeichnungen. Einerseits werde ich die Seite, erstmal zumindest, nur auf Deutsch erstellen, andererseits sind viele der gängigen Begriffe & Formulierungen im Webpublishing nunmal Englisch. Zumal sie meist auch noch deutlich kürzer sind und keine Umlaute enthalten (gut - bei den folgenden Beispielen trifft das eh alles nicht zu, aber man weiß ja nicht, was noch alles kommen kann):
Tag <-> Thema(?) oder Schlagwort (?)
Search <-> Suche
Searchresult <-> Suchergebnis

Mal abgesehen von den FOrmulierungen, sollte ich evt. am besten doch direkt ein Konzept wählen, dass eine spätere Mehrsprachigkeit möglichst einfach ermöglicht? Ich habe die fragliche Domain aber eh bereits unter den folgenden TLDs registriert: de, eu und info (com war leider schon besetzt). So könnte ich ja später einfach eine Englisch sprachige Version unter eu oder info anbieten. Bisher leiten diese Domains auf die de weiter.

Ein weiterer Punkt, der mir Kopfzerbrechen bereitet, ist die Sache mit dem Query String. Was mir sehr plausibel erscheint ist, dass es keine schlechte Idee ist, einen vorhandenen QS auf die enthaltenen Variablen zu prüfen und nur die durchzulassen, die als "erlaubt" hinterlegt sind. Auch könnte man darauf achten, dass bspw. nur die benötigten Variablen, d.h. die mit einem Wert, und stets in gleicher Reihenfolge sortiert im QS vorkommen.
Frage: Lohnt sich der Aufwand? Einfachere Möglichkeit?
Bisher weiß ich noch gar nicht, ob ich überhaupt eine Seite haben werde, die per GET Daten versendet.
Andererseits könnte man so bspw. aber auch häufig vorkommende Suchanfragen cachen (vorausgesetzt natürlich, die Suchbegriffe und -kriterien sind exakt gleich).

Und dann ist da noch das leidige Thema mit der "Besucher-Identifizierung/ -wiedererkennung". Denn ich würde dem User bspw. verschiedene Layouts (zumindest 2) anbieten wollen. Blöd nur, wenn der dann keine Kekse akzeptiert. Dann hätte ich in jedem Request die schei.. Session-ID. Oder gibt es für dieses Problem noch eine andere Lösung? Oder soll ich diesen Usern dann mitteilen, dass Cookies zwingend erforderlich sind für diese "Komfort-Funktion"?

Jetzt nochmal kurz zurück zu dem Thema "Kontextwechsel erkennen und behandeln".
Wenn ich den Request in meinem PHP-Script verarbeite, muss ich dann auch irgendetwas de-/codieren, oder kann ich einen evt. vorhandenen QS einfach so "abschneiden" und wieder "anhängen"? Und wie sieht es im Bezug auf evt, Prüfungen seitens z.B. str(i)pos oder preg_xxx aus?
Ich arbeite UTF-8 codiert und gebe auch meine Seiten so aus (also serverseitig so konfiguriert).
Dieses Thema treibt mich noch in den Wahnsinn! ;-)
Einerseits soll ja alles richtig funktionieren und korrekt ausgegeben werden, andererseits will ich aber ja auch keine (unnötigen) Kodier-Orgien veranstalten.

Es wäre wirklich sehr nett, wenn du/ ihr mir hier nochmal weiterhelfen könntet - danke!

Gruß Gunther

[ChrisB]

Hi,

Etwas unsicherer bin ich mir schon bei der Suche. Ich dachte bisher an etwas wie:
Suchseite: http://example.com/Search:
Ergebnisseite: http://example.com/Search(result?):CSS+HTML+Usability

Ich würde die Suchseite selber vielleicht nur
http://example.com/Search
nennen - das wäre analog dazu, unter /search.php nur das Suchformular auszuliefern, und unter
http://example.com/Search:Suchbegriff
dann die Ergebnisse zu diesem Suchbegriff, analog zu /search.php?query=Suchbegriff

Ein weiterer Punkt, der mir Kopfzerbrechen bereitet, ist die Sache mit dem Query String. Was mir sehr plausibel erscheint ist, dass es keine schlechte Idee ist, einen vorhandenen QS auf die enthaltenen Variablen zu prüfen und nur die durchzulassen, die als "erlaubt" hinterlegt sind. Auch könnte man darauf achten, dass bspw. nur die benötigten Variablen, d.h. die mit einem Wert, und stets in gleicher Reihenfolge sortiert im QS vorkommen.
Frage: Lohnt sich der Aufwand?

Weiss ich nicht.
Das Querystring-Parameter i.a.R. keine bestimmte Reihenfolge voraussetzen, ist generell erst mal ein Vorteil, den man durch Nutzung von mod_rewrite für "sprechendere" URLs sowieso erst mal zu nichte macht.

Bisher weiß ich noch gar nicht, ob ich überhaupt eine Seite haben werde, die per GET Daten versendet.

Tritt bei mir auch mehr und mehr in den Hintergrund - kommen eigentlich so gut wie nur noch bei AJAX-Requests zu Zuge, wo mich "schöne" URLs nicht so interessieren (müssen).

Andererseits könnte man so bspw. aber auch häufig vorkommende Suchanfragen cachen (vorausgesetzt natürlich, die Suchbegriffe und -kriterien sind exakt gleich).

Ob du nun /Search:Suchbegriff oder ?search.php?query=Suchbegriff cachen lässt, macht doch keinen Unterschied?

Und dann ist da noch das leidige Thema mit der "Besucher-Identifizierung/ -wiedererkennung". Denn ich würde dem User bspw. verschiedene Layouts (zumindest 2) anbieten wollen. Blöd nur, wenn der dann keine Kekse akzeptiert. Dann hätte ich in jedem Request die schei.. Session-ID. Oder gibt es für dieses Problem noch eine andere Lösung? Oder soll ich diesen Usern dann mitteilen, dass Cookies zwingend erforderlich sind für diese "Komfort-Funktion"?

Würde ich machen, ja.
Zwei verschiedenen Layouts ändern an den Daten selber nichts - also sehe ich auch keinen Grund, diese unter zwei verschiedenen Adressen anzubieten.

Jetzt nochmal kurz zurück zu dem Thema "Kontextwechsel erkennen und behandeln".
Wenn ich den Request in meinem PHP-Script verarbeite, muss ich dann auch irgendetwas de-/codieren, oder kann ich einen evt. vorhandenen QS einfach so "abschneiden" und wieder "anhängen"?

Die übliche kontextgerechte Behandlung wirst du natürlich durchführen - sonst hast du genauso wie mit PATH_INFO ein XSS-Problem, wenn du das, was der Client dir schickt, einfach durchreichst.

MfG ChrisB

[Gunther]

Hi,

auch hier erstmal noch mein Dank für die klaren Aussagen, wie du es machen würdest - das hilft einem doch erheblich bei der Entscheidungsfindung.

Etwas unsicherer bin ich mir schon bei der Suche. Ich dachte bisher an etwas wie:
Suchseite: http://example.com/Search:
Ergebnisseite: http://example.com/Search(result?):CSS+HTML+Usability

Ich würde die Suchseite selber vielleicht nur
http://example.com/Search
nennen - das wäre analog dazu, unter /search.php nur das Suchformular auszuliefern, und unter
http://example.com/Search:Suchbegriff
dann die Ergebnisse zu diesem Suchbegriff, analog zu /search.php?query=Suchbegriff

Ja, ist irgendwie "stimmiger" vom System her.
Werde ich so machen -> erledigt!

Ein weiterer Punkt, der mir Kopfzerbrechen bereitet, ist die Sache mit dem Query String. Was mir sehr plausibel erscheint ist, dass es keine schlechte Idee ist, einen vorhandenen QS auf die enthaltenen Variablen zu prüfen und nur die durchzulassen, die als "erlaubt" hinterlegt sind. Auch könnte man darauf achten, dass bspw. nur die benötigten Variablen, d.h. die mit einem Wert, und stets in gleicher Reihenfolge sortiert im QS vorkommen.
Frage: Lohnt sich der Aufwand?

Weiss ich nicht.
Das Querystring-Parameter i.a.R. keine bestimmte Reihenfolge voraussetzen, ist generell erst mal ein Vorteil, den man durch Nutzung von mod_rewrite für "sprechendere" URLs sowieso erst mal zu nichte macht.

Die Sortierung würde ja wenn eh nur in der internen Verarbeitung stattfinden.

Bisher weiß ich noch gar nicht, ob ich überhaupt eine Seite haben werde, die per GET Daten versendet.

Tritt bei mir auch mehr und mehr in den Hintergrund - kommen eigentlich so gut wie nur noch bei AJAX-Requests zu Zuge, wo mich "schöne" URLs nicht so interessieren (müssen).

Genau. Nach meiner bisherigen Vorstellung soll es bei mir ähnlich werden. So überlege ich bspw., ob ich die Kommentare auf einer Artikel-Seite per AJAX nachlade, anstatt diese von vornherein gleich mitzusenden (oft machen die Kommentare ja mehr aus, als der eigentliche Artikel). Und mit einem Fallback, falls kein JS verfügbar, bzw. deaktiviert ist, sofern ich das hinbekomme, ohne den Rest meines Konzepts über den Haufen werfen zu müssen. ;-)
Einen Tipp, wie man das am sinnvollsten anstellt?

Andererseits könnte man so bspw. aber auch häufig vorkommende Suchanfragen cachen (vorausgesetzt natürlich, die Suchbegriffe und -kriterien sind exakt gleich).

Ob du nun /Search:Suchbegriff oder ?search.php?query=Suchbegriff cachen lässt, macht doch keinen Unterschied?

Nein, macht es nicht. Es wäre halt nur "einfacher" festzustellen, ob eine Suchanfrage tatsächlich identisch mit einer bereits gecachten ist. Nach meiner bisherigen Idee, möchte ich ja u.a. auch eine erweiterte Suchmöglichkeit anbieten, die u.a. wahlweise eine AND oder OR Verknüpfung von Tag-Names erlaubt.

Und dann ist da noch das leidige Thema mit der "Besucher-Identifizierung/ -wiedererkennung". Denn ich würde dem User bspw. verschiedene Layouts (zumindest 2) anbieten wollen. Blöd nur, wenn der dann keine Kekse akzeptiert. Dann hätte ich in jedem Request die schei.. Session-ID. Oder gibt es für dieses Problem noch eine andere Lösung? Oder soll ich diesen Usern dann mitteilen, dass Cookies zwingend erforderlich sind für diese "Komfort-Funktion"?

Würde ich machen, ja.
Zwei verschiedenen Layouts ändern an den Daten selber nichts - also sehe ich auch keinen Grund, diese unter zwei verschiedenen Adressen anzubieten.

Danke für die "Bestätigung". Ich bin mittlerweile eh mehr und mehr der Ansicht, dass man Cookies und Javascript für Dinge des "Komforts" eben einfach voraussetzen darf - wer das, aus welchen Gründen auch immer, nicht möchte, der hat halt Pech.

Jetzt nochmal kurz zurück zu dem Thema "Kontextwechsel erkennen und behandeln".
Wenn ich den Request in meinem PHP-Script verarbeite, muss ich dann auch irgendetwas de-/codieren, oder kann ich einen evt. vorhandenen QS einfach so "abschneiden" und wieder "anhängen"?

Die übliche kontextgerechte Behandlung wirst du natürlich durchführen -

Natürlich! ;-)
Ich habe dedlfixs Artikel dazu ja schon gründlich studiert.

sonst hast du genauso wie mit PATH_INFO ein XSS-Problem, wenn du das, was der Client dir schickt, einfach durchreichst.

Ja. Wobei ich (bis jetzt zumindest) die PATH_INFO lediglich zum Vergleich heranziehe, ob sich ein passender Eintrag in der DB befindet.
Ansonsten würde eine Behandlung mit htmlspecialchars() aber schon mal das Schlimmste verhindern, oder übersehe ich etwas?

Besten Dank nochmal - hat mir sehr weitergeholfen!

Gruß Gunther

[dedlfix]

Hi!

Eigentlich wäre mir auch am liebsten, dass man im Root-Verzeichnis "manuell" gar keine Datei aufrufen kann, wobei ich mir nicht ganz im Klaren darüber bin, ob das wirklich geht, bzw. sinnvoll ist? Zwar liegen eben fast alle anderen Files in separaten Directories, aber für die Bots bspw. gibt es natürlich eine robots.txt!

Wenn du damit Dateien meinst, die nur für die Response-Erzeugung notwendig sind, aber sonst nicht ausgeliefert werden sollen (beispielsweise Include-Dateien) oder dürfen (Konfigurationsdateien), dann solltest du diese Dateien außerhalb des Documentroots lagern. Es muss natürlich auch beim Provider konfigurierbar sein, Domains auf Unterverzeichnisse seines Kundenverzeichnisses zeigen zu lassen, sprich: das Documentroot ist eines dieser Unterverzeichnisse. Bei jedem Provider, bei dem man mehrere Domains in seinem Paket verwalten kann, sollte das problemlos möglich sein.

/kunden/Gunther/  - Kundenverzeichnis
/kunden/Gunther/domain1/ - DocumentRoot der ersten Domain
/kunden/Gunther/domain1/images/
/kunden/Gunther/domain1/css/
/kunden/Gunther/domain2/ - DocumentRoot der zweiten Domain
/kunden/Gunther/domain2/...
/kunden/Gunther/dateien/ - kein DocumentRoot, vom Web aus nicht erreichbar

oder auch

/kunden/Gunther/  - Kundenverzeichnis
/kunden/Gunther/projekt1/
/kunden/Gunther/projekt1/web/ - DocumentRoot der ersten Domain
/kunden/Gunther/projekt1/web/images/
/kunden/Gunther/projekt1/web/css/
/kunden/Gunther/projekt1/dateien/
/kunden/Gunther/projekt2/
/kunden/Gunther/projekt2/web/ - DocumentRoot der zweiten Domain
/kunden/Gunther/projekt2/...

Es muss natürlich sichergestellt sein, dass alle Domains auf Unterverzeichnisse zeigen, auch die vom Provider zu Verwaltungszwecken bereitgestellte, wie die s+ziffernfolge.kundenserver.de von 1&1.

Lo!