hotti: Eigene Dateierweiterung für WebRessourcen festlegen

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

--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
  1. 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

    --
    RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
    1. 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

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

      1. [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

        --
        Dank Hixies Idiotenbande geschieht grade eben wieder ein Umdenken
        in Richtung "Mess up the Web".(suit)
        SelfHTML-Forum-Stylesheet
        1. [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 es

          http://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