Apache .htaccess - Verwendung so korrekt?

[Der Martin]

Hallo Peter,

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?
Das verstehe ich nicht so ganz, denn die Subdomains verweisen ja auf ein und denselben Quellordner.

ja, davon "weiß" aber der Browser nichts, der die JS-Sessourcen anfordert. Der Browser weiß nur: Das HTML-Dokument hat er von en.example.org bekommen, das JS dazu von en.example.org/gui/js.

Da die JS-Files durch PHP geparsed werden, greift hier der uebliche i18n-Mechnismus. Was genau meinst du mit der doppelten Datenhaltung?

Okay, ich sehe den Punkt: Alles wird über en.example.org angefordert, landet aber serverintern dennoch im gleichen Verzeichnis. Okay, da hatte ich nicht weit genug gedacht.

Denn, wie oben beschrieben, fuehren ja sowohl de.example.org/images/foo.bar als auch en.example.org/images/foo.bar auf dieselbe Resource.

<haarspalter>Nein, es sind unterschiedliche Ressourcen, aber sie werden auf dieselbe Datei abgebildet.</haarspalter>
Und ja, aus der Sicht des Clients liegt alles unter derselben Domain, aus der Sicht des Servers führt vieles auf dieselbe Datei. Also ist das Konzept besser, als es mir erst erschien.

Unterm Strich: Ich halte es für schlauer, verschiedene Sprachversionen nicht durch eine Subdomain zu unterscheiden, sondern durch ein Verzeichnis:
Aber, um an deinem Beispiel festzuhalten, dann bestuende doch das gleiche Problem wenn ich zb die Image in eine eigene Subdomain auslagere?

Ja, deswegen will ich auch Bilder, Stylesheets oder JS nicht in eine weitere, sprachunabhängige Subdomain auslagern.

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.
Letztere Moeglichkeit ist gegeben. Erstere war auch vor der Umstellung auf die Language-Subdomains vorhanden. Allerdings bin ich daran gescheitert dieses unter Apache entsprechend zu konfigurieren. Denn in der Datenbank existiert die Definition, welche Sprachen erlaubt sind und welche nicht. Und an dieser Stelle muesste ja eine Interaktion stattfinden.

Richtig. Ein PHP-Script auf www.example.org, das den Request gegen die verfügbaren Sprachversionen checkt und entsprechend weiterleitet, wäre da vermutlich einfacher, als alles über die Apache-Konfiguration abzufrühstücken.

Unter PHP arbeite ich fuer Includes stets mit dirname(__FILE__). Und durch meine virtuellen URLs stiesz ich hierbei auf Probleme. Denn die Includeangabe griff zb fuer die Adresse example.org/sektor1/sektor2, jedoch nicht fuer example.org/sektor1/sektor2/region1/myname.

Das wird mir nicht klar.

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.
Wieso unueblich?

Für "unüblich" halte ich nur, die mit DirectoryIndex referenzierte Datei über Verzeichnisgrenzen hinaus anzusprechen.

Oder spielst du darauf an eine Index-Datei durchaus in das Root zu packen, dort jedoch ein Redirect auf die entsprechende Seite vorzunehmen?

Nein, kein Redirect, höchstens ein Include verschiedener Abschnitte je nach angeforderter Seite. Aber darauf wollte ich gar nicht hinaus, sondern darauf, dass durch die relative Angabe des DirectoryIndex das tatsächliche Ziel möglicherweise nicht existiert. Beispiel (unter der Voraussetzung, dass ein Verzeichnis /foo auf dem Server existiert):

Request  http://en.example.org/
liefert  /source/view/index.html         korrekt

Request  http://en.example.org/foo/
liefert  /foo/source/view/index.html     vermutlich nicht korrekt

Wenn ich mit dem PHP-Header arbeite, bekaeme dann eigentlich die Suchmaschine etwas davon mit?

Du meinst den HTTP-Header? Natürlich. Schließlich sagst du damit dem Client bloß: Versuch's nochmal unter einer anderen URL. Daher würde ich internes Rewriting oder including bevorzugen.

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.
Wie habe ich das zu verstehen?

Analog zum oben ausgeführten Beispiel zum DirectoryIndex.

Saemtliche Resourcen binden zb obige Dateien einfach durch require('test.ajax') ein.

Das spielt keine Rolle; PHP selbst greift ja übers Dateisystem zu. (Du machst doch kein HTTP-include?!)

Das gleiche geschieht bei den AJAX-Aufrufen im Javascript selbst. Und, unabhaengig von dem Pfad, in dem sich die Dateien befinden, greift die RewriteEngine wie gewuenscht.

Aber abhängig von dem Pfad, den sie ansprechen.

<Files main.css>
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.
In dem von mir geposteten Beispiel gibt es eine solche Regel nicht?

Stimmt - ich hab mich von den vielen RewriteRules verwirren lassen. ;-)

So long,
 Martin