Der Martin: Apache .htaccess - Verwendung so korrekt?

Beitrag lesen

Hallo,

Vorab gesagt, es funktioniert so, wie ich es mir wuensche.

das ist schon mal gut, aber mir sieht das Gerüst etwas nach "Overkill" aus. Ich weiß allerdings auch nicht, wie umfangreich die Projekte sind, die du damit realisieren willst; vielleicht relativiert sich das dann.

  • Fuer jede moegliche Sprache existiert eine Subdomain
  • "en" ist Standard
  • "www" wird zu "en" weitergeleitet

Damit legst du dir selbst Fallstricke, z.B. wenn du Javascript verwenden willst (oder mal einzelne Seiten über SSL laufen lässt). Willst du dann tatsächlich alle Javascript-Ressourcen, die zum größten Teil sprachneutral sind, auf jeder Domain separat vorhalten? Denn das müsstest du dann, weil beispielsweise en.example.org und source.example.org aus der Sicht von JS zwei völlig getrennte Domains sind - du hättest also ständig mit der Same Origin Policy zu kämpfen.
Das gleiche gilt für eingebundene Bilder: Lagerst du sie z.B. von de.example.org auf images.example.org aus, werden sich einige Nutzer wundern, die ihren Browser nur Bilder laden lassen, die von derselben Domain stammen.

Unterm Strich: Ich halte es für schlauer, verschiedene Sprachversionen nicht durch eine Subdomain zu unterscheiden, sondern durch ein Verzeichnis:

www.example.org/de/
 www.example.org/en/

Dann hast du für alle Ressourcen denselben Hostnamen und kannst für sprachübergreifende Teile auch gemeinsame Verzeichnisse anlegen.

Nutze außerdem Language Negotiation, um von www auf die sprachspezifische Version zu leiten, lass aber dem Besucher jederzeit die Möglichkeit, manuell die Sprache zu wechseln und damit die Einstellungen seines Browsers zu übersteuern.

  • Alle *.css, *.js, *.tpl und *.ajax -Anfragen werden automatisch an ihren entsprechenden Ordner deligiert.
    Somit brauche ich fuer die Einbindung dieser Resourcen keine Pfade anzugeben.

Dann aber Vorsicht bei relativen Pfadangaben z.B. *innerhalb* von Stylesheets oder Javascripts. Die gehen dann nämlich nicht vom tatsächlichen Verzeichnis aus, in dem die Datei liegt, sondern von dem Verzeichnis, das du über das Rewriting vorgaukelst.

  • *.css, *.js, *.tpl und *.ajax -Files werden als PHP geparsed (nicht alle)

Hm.

Fuer o.g. Ansprueche habe ich mir nun folgende .htaccess-Datei erstellt:

Und warum markierst du Apache-Syntax hier als SQL? ;-)

----------------------------------------------------------------

Enable Rewrite Engin

----------------------------------------------------------------

Stimmt - von Engin habe ich hier schon eine Weile nichts mehr gelesen. Ist der verschwunden?  .oO(?)

----------------------------------------------------------------

Define the initial Page

----------------------------------------------------------------

DirectoryIndex  sources/view/index.html

Das ist sehr unüblich, aber möglich. Beachte aber, dass z.B. beim Aufruf von en.example.org/sources dann auf sources/sources/view/index.html verwiesen wird. Merke: Pfadangaben im DirectoryIndex können problematisch sein.

----------------------------------------------------------------

Define the Sources-Folder for HTML-Pages

----------------------------------------------------------------

RewriteRule ^([^/]+.html)$ sources/view/$1 [L]

Auch diese Direktive verweist für jeden Request auf eine HTML-Ressource zwei Verzeichnisebenen tiefer. Das muss nicht immer richtig sein!

----------------------------------------------------------------

Redirect every CSS-Request to the CSS-Folder

----------------------------------------------------------------

RewriteRule ([^/]+.css) gui/css/$1 [L]

----------------------------------------------------------------

Redirect every JavaScript-Request to the CSS-Folder

----------------------------------------------------------------

RewriteRule ([^/]+.js) gui/js/$1 [L]

----------------------------------------------------------------

Redirect every AJAX-Request to the Ajax-Folder

----------------------------------------------------------------

RewriteRule ([^/]+.ajax) sources/ajax/$1 [L]

Die sind alle relativ zum Request-Pfad und können daher ins Nirwana gehen, wenn der Request nicht auf das Domain-Root-Verzeichnis verweist.

----------------------------------------------------------------

Parse the main CSS-File as PHP

----------------------------------------------------------------

<Files main.css>
ForceType application/x-httpd-php
</Files>

----------------------------------------------------------------

Parse the Google-Maps JavaScript-File as PHP

----------------------------------------------------------------

<Files maps.js>
ForceType application/x-httpd-php
</Files>

Die beiden hast du doch mit der allgemeinen Regel, alle CSS- und JS-Ressourcen mit PHP zu parsen, schon abgedeckt.

Ein weiterer Punkt, den ich mit meinem derzeitigen Wissensstand noch nicht so ganz ueberschaue, waere SEO bzw. wie sich die einzelnen Rewrites auf die Suchmaschinen auswirken bzw. ob die davon ueberhaupt etwas mitbekommen.

Von außen ist nur der Redirect von www.example.org nach en.example.org sichtbar. Alles andere läuft serverintern und ist für einen HTTP-Client nicht erkennbar.

Ciao,
 Martin

--
Besteht ein Personalrat aus nur einer Person, erübrigt sich die Trennung nach Geschlechtern.
  (aus einer Info des deutschen Lehrerverbands Hessen)