URL nicht existierende Dateien vorgaukeln

**ghostgambler** · 19.05.2006, 23:16

Re: URL nicht existierende Dateien vorgaukeln

suche("mod_rewrite")

auch wenn ich davon nicht viel halte *shrug*

**MaxP0W3R** · 20.05.2006, 00:09

Re: Re: URL nicht existierende Dateien vorgaukeln

Original geschrieben von ghostgambler
auch wenn ich davon nicht viel halte *shrug* [/B]

Warum ?

**ghostgambler** · 20.05.2006, 06:55

Re: Re: Re: URL nicht existierende Dateien vorgaukeln

Original geschrieben von MaxP0W3R
Warum ?

* vernünftige Suchmaschinen schaffen den Umgang mit vernünftig gewählten get-Parametern ohne Probleme.
* mit mod_rewrite belastet man den Server mit unnützer Last (und davon nicht gerade wenig), wo man die Resourcen besser für was anderes benutzen kann.
* Bugs in mod_rewrite sind schwer zu debuggen

Da bevorzuge ich lieber path_info in Kombination mit Endungslosen php-Dateien. Dann gibt es URLs allá
www.blabla.de/news/45
wobei news in wirklichkeit ein Skript ist und die 45 per path_info übergeben wird. Wenn man die Einstellungen in der httpd.conf vornimmt, belastet das den Server kaum und wenn man dazu noch ein wenig geschickt im Umgang mit den Variablen ist, gibt es kein Sicherheitsproblem ... ist für mich definitiv die bevorzugte Lösung ^^,

**wahsaga** · 22.05.2006, 09:49

Re: Re: Re: Re: URL nicht existierende Dateien vorgaukeln

Original geschrieben von ghostgambler
* vernünftige Suchmaschinen schaffen den Umgang mit vernünftig gewählten get-Parametern ohne Probleme.

Es geht nicht immer darum, SuMas hinterherzuhecheln.

Auch "Menschen" - schon mal davon gehört? - lesen URLs.
Und für die kann ein "sprechender" URL oftmals sehr viel schöner sein, als irgendein GET-Gewurstel.

* mit mod_rewrite belastet man den Server mit unnützer Last (und davon nicht gerade wenig), wo man die Resourcen besser für was anderes benutzen kann.

Ah, geh - das bisschen ist deinem Server auch längst egal.
(Es sei denn, man baut seine Regeln wirklich ungeschickt auf ...)

* Bugs in mod_rewrite sind schwer zu debuggen

Auch das geht leidlich.
Natürlich nur, wenn man auch die Möglichkeiten hat, entsprechendes Logging einzustellen, etc. - also erst mal auf der eigenen Maschine testen.

Da bevorzuge ich lieber path_info [...]
Wenn man die Einstellungen in der httpd.conf vornimmt, belastet das den Server kaum

Dafür muss die Arbeit des "parsens" der Parameter jetzt dein PHP-Script übernehmen.
Und wenn das nicht nur in einfachem "Auseinanderpflücken" besteht, sondern auch noch in Plausibilisierungen auf bspw. Zeichenbereiche o.ä. - dann wirfst du jedes mal erst mal den PHP-Parser an, auch wenn du die Daten dann vielleicht abweist - während im anderen Falle mod_rewrite das bereits gemacht hat, noch bevor irgendwer den PHP-Parser bemühen musste ...

**Koala** · 22.05.2006, 09:59

und wie sieht das mit mod_rewrite in Bezug auf Barrierefreiheit aus?

**wahsaga** · 22.05.2006, 10:10

Original geschrieben von Koala
und wie sieht das mit mod_rewrite in Bezug auf Barrierefreiheit aus?

Kannst du etwas präzisieren, was du in Bezug auf diese Thematik mit "Barrierefreiheit" meinst - oder gehörst du nur zu den Leuten, die das Schlagwort immer so gerne benutzen, ohne ansatzweise zu wissen, was dahintersteckt?

**Koala** · 22.05.2006, 10:42

mich interessiert ob es Blinden möglich ist zu entziffern auf welcher Seite sie sich befinden wenn die url mit mod_rewrite umgeschrieben wird, oder ob es egal ist wenn immer z.B. index.htm dasteht obwohl die Seite eine andere ist.

**wahsaga** · 22.05.2006, 10:44

Original geschrieben von Koala
mich interessiert ob es Blinden möglich ist zu entziffern auf welcher Seite sie sich befinden wenn die url mit mod_rewrite umgeschrieben wird, oder ob es egal ist wenn immer z.B. index.htm dasteht obwohl die Seite eine andere ist.

Hat in beiden Fällen doch wohl nicht das geringste damit zu tun, ob der Besucher blind ist.

**ghostgambler** · 22.05.2006, 10:48

Re: Re: Re: Re: Re: URL nicht existierende Dateien vorgaukeln

Original geschrieben von wahsaga
Auch "Menschen" - schon mal davon gehört? - lesen URLs.
Und für die kann ein "sprechender" URL oftmals sehr viel schöner sein, als irgendein GET-Gewurstel.

dafür reicht auch path_info, ich habe nirgens etwas von get gesagt ^^,

Ah, geh - das bisschen ist deinem Server auch längst egal.
(Es sei denn, man baut seine Regeln wirklich ungeschickt auf ...)

wenn ich aber ohne mod_rewrite, das komplette Modul weglassen kann, spart das Overhead beim Apache

Auch das geht leidlich.
Natürlich nur, wenn man auch die Möglichkeiten hat, entsprechendes Logging einzustellen, etc. - also erst mal auf der eigenen Maschine testen.

ist aber definitiv komplizierter als bei einem php-Skript

Dafür muss die Arbeit des "parsens" der Parameter jetzt dein PHP-Script übernehmen.
Und wenn das nicht nur in einfachem "Auseinanderpflücken" besteht, sondern auch noch in Plausibilisierungen auf bspw. Zeichenbereiche o.ä. - dann wirfst du jedes mal erst mal den PHP-Parser an, auch wenn du die Daten dann vielleicht abweist - während im anderen Falle mod_rewrite das bereits gemacht hat, noch bevor irgendwer den PHP-Parser bemühen musste ...

php kann mit preg_match auch relativ flott einen String validieren und da kann ich dann auch gleich Datenbankabfragen machen (z.B. existiert der Thread?), was ich in mod_rewrite eh nicht könnte. Und wenn ein falscher Input kommt, kann man auf eine adäquate Fehlerseite umleiten, während mod_rewrite einfach nicht greift und man im besten Falle einen 404 kriegt, oder im schlimmeren Fall ein kaputtes Skript, was sich halb dahinter verbirgt

**Koala** · 22.05.2006, 10:48

ok - dann ist es für nen Blinden also egal was da steht - thanx.

**wahsaga** · 22.05.2006, 11:05

Re: Re: Re: Re: Re: Re: URL nicht existierende Dateien vorgaukeln

Original geschrieben von ghostgambler
Und wenn ein falscher Input kommt, kann man auf eine adäquate Fehlerseite umleiten, während mod_rewrite einfach nicht greift und man im besten Falle einen 404 kriegt

Diese "adäquate Fehlerseite" einfach als ErrorDocument für 404 zu definieren, sollte ja auch kein Problem sein.

URL nicht existierende Dateien vorgaukeln