Peter Nack: Apache .htaccess - Verwendung so korrekt?

Beitrag lesen

Hallo Martin,

ich merke bereits, die Sache ist es doch wert mich ein wenig detaillierter damit zu beschaeftigen ;)

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.

Stimmt. Somit wuerde ich ungewollter Weise die Caching-Mechanismen des Browsers umgehen.

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.

Ja. Allerdings ein wenig modifiziert. Alle Verweise referenzieren auf example.org. Da diese auf en.example.org umgeschrieben wird, ist es egal von welcher Subdomain aus man darauf zugreift. Die Sprach-Subdomain fungiert eigentlich lediglich als Platzhalter repsektive Angabe der Sprache. Die Verarbeitung einzelner Sprachsubdomains ist jeweils identisch.

ABER: Deine oben zitierte Analyse zeigt mir dann doch, dass das vielleicht doch nicht so optimal ist, wie ich es mir gedacht habe (Stichwort Browsercache).

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>

Exakt. Da hast du vollkommen recht.

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.

S.o. Nun erscheint es fuer dich besser, auf meiner Seite kommen jedoch Zweifel auf. Klassischer Seitenwechsel ;-)

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.

Ja, zu der Einsicht bin ich nun auch gelangt.

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.

Sorry, habe gerade noch einmal ein wenig rumgespielt und konnte meine Beschreibungen nicht mehr nachvollziehen. Also diese Sache einfach vergessen.

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

Was verstehst du in diesem Kontext unter Verzeichnisgrenzen? Wer setzt diese Begrenzungen?

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

Die Frage ist, wie man "korrekt" definiert. Wenn an dieser Stelle ein 404er geschmissen wird, so ist das ja korrekt. Denn schlieszlich existiert die Datei/Resource ja nicht.

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.

Ja. Verstanden.

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?!)

Nein, natuerlich nicht. Ich habe auch ein unschoenes Beispiel gewaehlt.
Nehmen wir an, wir haben eine JavaScript-Datei, welche unter example.org/gui/js/myjs.js liegt.
Dort findet ein Ajax-Request statt. Und statt an dieser Stelle den korrekt Pfad zu dem PHP-File zu ermitteln / anzugeben, reicht zb folgende Angabe aus:
$.getJSON("foo.ajax", [..]);
Unabhaengig davon, wo die Datei liegt, welche den Request absendet, landet sie immer unter example.org/sources/ajax/foo.ajax

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.

Wie meinen? S.o.

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

Ehrlich gesagt komme ich bei diesen ganzen Strukturueberlegungen und -Konfigurationen auch ganz schoen ins Schwanken.
Und es hat den Eindruck, je mehr ich mit dir ueber das Thema nachdenke, desto mehr Fragen tauchen auf. Aber das ist ja stets ein gutes Zeichen ;-)

Nochmal besten Dank fuer deine Denkanstoesze,
Peter