Eigene Dateierweiterung für WebRessourcen festlegen
hotti
- sonstiges
hi,
zum Eingrenzen meiner RewriteRule für ein bestimmtes Script mit einer bestimmten Aufgabenstellung
RewriteRule ^(.*).img$ /cgi-bin/images.cgi
möchte ich eine eindeutige Dateierweiterung '.img' festlegen, so wird z.B. mit Requ.Uri
/images/friseur/1.img
das erste Bild aus der Sammlung 'friseur' aufgerufen, mit 2.img das Zweite usw. (das Script erledigt dann alles).
Rein technisch geht das einwandfrei, die Frage ist die: Könnte das die Besucher oder auch die Bots verwirren? Und: Spielen da alle Browser mit?
Bitte mal um Hinweise,
Hotti
Hi,
zum Eingrenzen meiner RewriteRule für ein bestimmtes Script mit einer bestimmten Aufgabenstellung
RewriteRule ^(.*).img$ /cgi-bin/images.cgi
möchte ich eine eindeutige Dateierweiterung '.img' festlegen, so wird z.B. mit Requ.Uri
/images/friseur/1.img
das erste Bild aus der Sammlung 'friseur' aufgerufen, mit 2.img das Zweite usw. (das Script erledigt dann alles).
Und wofür soll dieses .img jetzt gut sein?
Dass wir uns in einem Bereich befinden, unter dem Bilder abrufbar sind, das suggeriert schon der Bestandteil /images/ in der Adresse.
Was soll jetzt noch das .img? Wieso tut's /images/friseur/1 nicht genauso gut, bzw. besser?
Rein technisch geht das einwandfrei, die Frage ist die: Könnte das die Besucher oder auch die Bots verwirren?
Der Besucher kann mit .img wenig anfangen. Eine bekannte „Dateiendung“ wie .jpg/.png/.gif würde ihm vielleicht noch was sagen - aber .img nicht.
Und: Spielen da alle Browser mit?
Beim Anzeigen ja, da ist denen das so egal, wie den Bots.
Probleme können sich ergeben, wenn der Nutzer die Seite offline abspeichern will - einmal im Dateisystem gelandet, bewirkt die Endung .img ggf. unbeabsichtigtes, wenn diese Datei direkt geöffnet werden soll.
(Dem gegenüber hätte /1 aber auch keinen Vorteil. Ggf. passt der Browser das beim Speichern von sich aus an. Außerdem ist lokales Abspeichern von Webseiten für mich ein extremer Sonderfall, der m.E. keine besonders große Berücksichtigung erfordert.)
MfG ChrisB
hi,
das erste Bild aus der Sammlung 'friseur' aufgerufen, mit 2.img das Zweite usw. (das Script erledigt dann alles).
Und wofür soll dieses .img jetzt gut sein?
Wie gesagt, zum Eingrenzen der Rewrite-Regel auf das spezielle Script.
Dass wir uns in einem Bereich befinden, unter dem Bilder abrufbar sind, das suggeriert schon der Bestandteil /images/ in der Adresse.
Was soll jetzt noch das .img? Wieso tut's /images/friseur/1 nicht genauso gut, bzw. besser?
Freilich, würde auch gehen. Ich könnte z.B. festlegen, dass "alles was nach ^images kommt" auf mein Script umgeschossen wird. Oder hast Du einen anderen/schöneren Vorschlag?
Der Besucher kann mit .img wenig anfangen. Eine bekannte „Dateiendung“ wie .jpg/.png/.gif würde ihm vielleicht noch was sagen - aber .img nicht.
Hmm, eigentlich wird ja HTML ausgegeben von dem Script. Aber 'html' habe ich schon in einer anderen Regel ('htm' sieht nach Windoof 3.1 aus *g).
Probleme können sich ergeben, wenn der Nutzer die Seite offline abspeichern will
Ok, das lassen wir mal Außen vor ;)
Vielen Dank schonmal,
Hotti
hi,
Was soll jetzt noch das .img? Wieso tut's /images/friseur/1 nicht genauso gut, bzw. besser?
Nu gut, ich habe das mal so gemacht wie vorgeschlagen. Das Script in der RewriteRule ist nun nicht mehr parametergesteuert, sondern nur noch vom REQUEST_URI bestimmt.
Btw., geht der Trend z.Z. völlig dahin, URLs ohne Dateierweiterungen zu erzeugen?
Hotti
[latex]Mae govannen![/latex]
Btw., geht der Trend z.Z. völlig dahin, URLs ohne Dateierweiterungen zu erzeugen?
Ob es ein Trend ist, ist zumindest für mich irrelevant, wichtig ist der Sinn dahinter.
Und Dateierweiterungen sind meines Erachtens bei Ressourcen, die nicht direkt aufzurufende Dateien sind, sinnfrei (in der Site-Kommunikation nach aussen wohlgemerkt)
Den End-Nutzer interessiert es ohnehin nicht, welche Technik hinter
http://example.com/foo.html
http://example.com/foo.php
http://example.com/foo.shtml
http://example.com/foo.pl
arbeitet, er will „nur“ den Inhalt.
http://example.com/foo
ist wesentlich griffiger und außerdem leichter zu merken :)
Bei Bildern gilt das auch, wenn nicht auf die Bilddatei selbst verwiesen wird, sondern z.B. ein Bild dynamisch in ein HTML-Dokument eingefügt wird. Wozu soll der Nutzer sich merken müssen, ob er
http://example.com/images/hotti_betrunken.png
http://example.com/images/hotti_betrunken.jpg
http://example.com/images/hotti_betrunken.jpeg
http://example.com/images/hotti_betrunken.gif
eingeben muß, wenn es
http://example.com/images/hotti_betrunken
auch tut?
Außerdem muß man z.B. bei einem Rewrite der Site mit einer anderen Technik nicht „lügen“, wenn die ehemals z.B. php-getriebene Site unter perl neu programmiert wurde und man aus Kompatibilitätsgründen immer noch foo.php annehmen müßte. Aber das ist natürlich nebensächlich.
Stur lächeln und winken, Männer!
Kai
[latex]Mae govannen![/latex]
Hi Kai,
http://example.com/foo
ist wesentlich griffiger und außerdem leichter zu merken :)
Einleuchtend.
Bei Bildern gilt das auch, wenn nicht auf die Bilddatei selbst verwiesen wird, sondern z.B. ein Bild dynamisch in ein HTML-Dokument eingefügt wird. Wozu soll der Nutzer sich merken müssen, ob er
[..]
eingeben muß, wenn eshttp://example.com/images/hotti_betrunken
auch tut?
Das ist einflößend, klasse Beispiel ;)
Außerdem muß man z.B. bei einem Rewrite der Site mit einer anderen Technik nicht „lügen“, wenn die ehemals z.B. php-getriebene Site unter perl neu programmiert wurde und man aus Kompatibilitätsgründen immer noch foo.php annehmen müßte. Aber das ist natürlich nebensächlich.
Ne, isses nicht: PHP hau wech, machs lieber gleich mit Perl ;)
Also ich bin seit ein paar Tagen in Aufruhr wegen dieser URI-Geschichten. Und freilich auch am Grübeln, wie ich das am Besten angehe. Auf jeden Fall nicht so, wie ich das hier immer lese, dass erst ein Script gebaut wird, was parametergesteuert ist und danach am Server schrauben, bis der URI auf die Parameter passt. Das muss genau andersherum angegangen werden, zuerst wird der URI festgelegt und damit das Script gesteuert. Ggf. wird der URI parametrisiert in einem Zwischenschritt.
Das nach diesem Muster gebaute Script zu http://rolfrost.de/images hat eine ganz einfache Kontrollstruktur, allerdings ist der Code mit geschachtelten Hash-Referenzen like $sam->{$names->{sam}}->{imgs}->{$names->{nr}}->{title} etwas gewöhnungsbedürftig um nicht zu sagen unübersichtlich, was sich mit einer passenderen Datenstruktur jedoch verbessern lässt.
Danke fürs Interess und Feedback,
Grüße an Alle,
Horst Männlich