Peter Nack: Apache .htaccess - Verwendung so korrekt?

SELF-Forum

Apache .htaccess - Verwendung so korrekt?

Peter Nack
– Informationen zu den Bewertungsregeln

Tag zusammen,

ich habe mich in letzter Zeit ein wenig in den Apache eingearbeitet.
Nutzte ich ihn vorher lediglich um PHP ausfuehren zu koennen, habe ich bei meinem aktuellen Projekt mal mehr mit den Moeglichkeiten rumgespielt, die mir der Apache vor allem mit der ausfuehrlichen RewriteEngine bietet.

Vorab gesagt, es funktioniert so, wie ich es mir wuensche.
Allerdings wuerde ich gerne mal von ein paar Fachleuten hier hoeren, ob ich die Sachen korrekt verstanden und auch richtig implementiert habe, oder ob ich mit meinen Konfigurationen evtl. in eine falsche Richtung gelaufen bin und ich eines Tages darueber stolpern werde.

Kurze Erlaeuterung meines strukturellen Aufbaus:

  • Fuer jede moegliche Sprache existiert eine Subdomain

  • "en" ist Standard

  • "www" wird zu "en" weitergeleitet

  • Alle moeglichen HTML-Files befinden sich unter /sources/view/. So auch meine Index.html

  • wenn in der URL die Angabe /items/ vorhanden ist, wird die Anfrage an eine spezielle Datei weitergeleitet und weitere Angaben erst durch diese Datei ausgewertet.
    Somit gewaehrleiste ich zb folgende virtuelle URLS:
    http://en.example.com/items/sektor1/subsektor2/regionXyZ/ItemName

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

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

  • eigenes 404-Error-Document

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

  
# ----------------------------------------------------------------  
# Enable Rewrite Engin  
# ----------------------------------------------------------------  
RewriteEngine on  
  
  
# ----------------------------------------------------------------  
# Redirect automatically to the en-subdomain  
# ----------------------------------------------------------------  
RewriteCond %{HTTP_HOST} www\.example\.dev$ [NC]  
RewriteRule ^(.*)$ http://en.example.dev/$1 [R=301,L]  
  
  
# ----------------------------------------------------------------  
# Define the initial Page  
# ----------------------------------------------------------------  
DirectoryIndex  sources/view/index.html  
  
  
# ----------------------------------------------------------------  
# Redirect Items-Requests to the corresponding Page  
# ----------------------------------------------------------------  
RewriteRule ^(items/).*$ sources/view/view_items.html  
  
  
# ----------------------------------------------------------------  
# Define the Sources-Folder for HTML-Pages  
# ----------------------------------------------------------------  
RewriteRule ^([^/]+\.html)$ sources/view/$1 [L]  
  
  
# ----------------------------------------------------------------  
# 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]  
  
  
# ----------------------------------------------------------------  
# Parse *.html-Files as PHP  
# ----------------------------------------------------------------  
AddType application/x-httpd-php .html  
  
  
# ----------------------------------------------------------------  
# Parse *.ajax-Files as PHP  
# ----------------------------------------------------------------  
AddType application/x-httpd-php .ajax  
  
  
# ----------------------------------------------------------------  
# Parse *.tpl-Files as PHP  
# ----------------------------------------------------------------  
<Files .tpl>  
	ForceType application/x-httpd-php  
</Files>  
  
  
# ----------------------------------------------------------------  
# 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>  
  
  
# ----------------------------------------------------------------  
# Handle 404-Errors on our own  
# ----------------------------------------------------------------  
ErrorDocument 404 /sources/view/error_404.html  
  
  
# ----------------------------------------------------------------  
# Increase PHP's Memory Limit  
# ----------------------------------------------------------------  
php_value memory_limit 128M

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. Und ob die Werte (zb [R=301,L]) fuer die Rewrites korrekt gesetzt sind.

Herzliche Dank im Voraus
Peter

Beitrag melden
–
Informationen zu den Bewertungsregeln

  1. Apache .htaccess - Verwendung so korrekt?

    Gunnar Bittersmann Homepage des Autors
    – Informationen zu den Bewertungsregeln

    @@Peter Nack:

    nuqneH

    • "en" ist Standard

    Warum das? Es ist angebracht, Sprachvereinbarung (language negotiation) einzusetzen. Warum sollte ein Nutzer mit der Sprachauswahl belastet werden, wenn es ihm eine Automatik doch abnehmen kann?

    Wir hatten vor kurzem erst eine ausführliche Diskussion darüber.

    Qapla'

    --
    Alle Menschen sind klug. Die einen vorher, die anderen nachher. (John Steinbeck)
    Beitrag melden
    –
    Informationen zu den Bewertungsregeln

  2. Apache .htaccess - Verwendung so korrekt?

    Der Martin
    – Informationen zu den Bewertungsregeln

    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)
    Beitrag melden
    –
    Informationen zu den Bewertungsregeln

    1. Apache .htaccess - Verwendung so korrekt?

      Peter Nack
      – Informationen zu den Bewertungsregeln

      Hallo Martin,

      erstmal vielen Dank fuer deine ausfuehrliche Antwort!

      • Fuer jede moegliche Sprache existiert eine Subdomain
        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. Da die JS-Files durch PHP geparsed werden, greift hier der uebliche i18n-Mechnismus. Was genau meinst du mit der doppelten Datenhaltung?

      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.

      Bezieht sich diese Aussage jetzt noch auf die Same Origin Policy? Denn, wie oben beschrieben, fuehren ja sowohl de.example.org/images/foo.bar als auch en.example.org/images/foo.bar auf dieselbe Resource.

      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?

      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.

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

      Vielleicht bringt es etwas wenn ich das _warum_ kurz erklaere.
      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.
      Es kann sehr gut sein, dass ich an dieser Stelle evtl. bereits eine falsche Abzweigung eingeschlagen habe.

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

      Im Falle von Mehrsprachigkeit hat sich diese Methode als die fuer mich Komfortabelste erwiesen.

      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? Bei mehreren hundert Seiten moechte ich doch schlieszlich eine saubere Struktur besitzen.
      Oder spielst du darauf an eine Index-Datei durchaus in das Root zu packen, dort jedoch ein Redirect auf die entsprechende Seite vorzunehmen?
      Wenn ich mit dem PHP-Header arbeite, bekaeme dann eigentlich die Suchmaschine etwas davon mit?

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

      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.

      Wie habe ich das zu verstehen? Saemtliche Resourcen binden zb obige Dateien einfach durch require('test.ajax') ein. 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.

      <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? Diese beiden Files sind die einzigen CSS- und JS-Dateien, die derzeit von PHP geparsed werden.

      Hoffe ich habe deine Ausfuehrungen korrekt verstanden.
      Nochmals besten Dank!

      MfG
      Peter

      Beitrag melden
      –
      Informationen zu den Bewertungsregeln

      1. Apache .htaccess - Verwendung so korrekt?

        Der Martin
        – Informationen zu den Bewertungsregeln

        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

        --
        Elefant zum Kamel: "Sag mal, wieso hast du denn den Busen auf dem Rücken?"
        Kamel:             "Ziemlich freche Frage für einen, der den Penis im Gesicht hat."
        Beitrag melden
        –
        Informationen zu den Bewertungsregeln

        1. Apache .htaccess - Verwendung so korrekt?

          Peter Nack
          – Informationen zu den Bewertungsregeln

          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

          Beitrag melden
          –
          Informationen zu den Bewertungsregeln

    2. Apache .htaccess - Verwendung so korrekt?

      Edgar Ehritt
      – Informationen zu den Bewertungsregeln

      Hallo Martin,

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

      der ist in der Lounge und chillt noch ein wenig bei teils weltverschwörerischen Theorien. ;(

      Gruß aus Berlin!
      eddi

      Beitrag melden
      –
      Informationen zu den Bewertungsregeln

      1. Apache .htaccess - Verwendung so korrekt?

        Der Martin
        – Informationen zu den Bewertungsregeln

        Hallo Eddi,

        Stimmt - von Engin habe ich hier schon eine Weile nichts mehr gelesen. Ist der verschwunden?  .oO(?)
        der ist in der Lounge und chillt noch ein wenig bei teils weltverschwörerischen Theorien. ;(

        nö, auch in der Lounge ist es seit ein paar Tagen verdächtig ruhig ...

        Ciao,
         Martin

        --
        Bitte komme jemand mit einem *g* zum Wochenende, damit nicht über mich gelacht wird.
          (Gunnar Bittersmann)
        Beitrag melden
        –
        Informationen zu den Bewertungsregeln

        1. Apache .htaccess - Verwendung so korrekt?

          Kai345 Homepage des Autors
          – Informationen zu den Bewertungsregeln

          [latex]Mae  govannen![/latex]

          Stimmt - von Engin habe ich hier schon eine Weile nichts mehr gelesen. Ist der verschwunden?  .oO(?)
          der ist in der Lounge und chillt noch ein wenig bei teils weltverschwörerischen Theorien. ;(

          nö, auch in der Lounge ist es seit ein paar Tagen verdächtig ruhig ...

          Ähm, ist es nicht in der Regel so, daß Verschwörungsanhänger in bulligen, schwarzen Autos verschwinden und dann in kargen (Keller)Räumen Verhöre und Experimente an ihnen durchgeführt werden? Dort gibt es halt keinen Internetzugang :)

          Cü,

          Kai

          --
          A workaround for an avoidable problem often adds clutter and overhead to the program which
          could have been avoided by not creating the problem in the first place.(Garrett Smith/clj)
          Foren-Stylesheet Site Selfzeug JS-Lookup
          SelfCode: sh:( fo:| ch:? rl:( br:< n4:( ie:{ mo:| va:) js:| de:> zu:) fl:( ss:| ls:?
          Beitrag melden
          –
          Informationen zu den Bewertungsregeln

  3. Apache .htaccess - Verwendung so korrekt?

    Edgar Ehritt
    – Informationen zu den Bewertungsregeln

    Hallo Peter,

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

    Redirect automatically to the en-subdomain

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

    RewriteCond %{HTTP_HOST} www.example.dev$ [NC]

    Bedenke auch Aufrufe ohne der Psyeudosubdomain "www."
    RewriteCond %{HTTP_HOST} (www\.)?example\.dev$

    RewriteRule ^(.*)$ http://en.example.dev/$1 [R=301,L]

    Hier würde ich anders vorgehen. Es handelt sich um eine Sprachweiche, was sich auf HTTP-Ebene besser als "Gefunden" denn "Verschoben" repräsentieren lässt:
    RewriteRule ^(.*)$ http://en.example.dev/$1 [R=302,L]

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

    Redirect every AJAX-Request to the Ajax-Folder

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

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

    Vermutlich hast Du es gemacht, aber in den geposteten Ausschnitt der Konfiguration nicht eingefügt, ansonsten für unbekannte Dateitypen ("ajax" ist nicht in der mime.types nicht eingetragen) immer mit AddType den Mediatypen setzen.

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

    Parse *.html-Files as PHP

    Parse *.ajax-Files as PHP

    Parse *.tpl-Files as PHP

    Parse the main CSS-File as PHP

    Parse the Google-Maps JavaScript-File as PHP

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

    <FilesMatch "(^maps\.(js|css)|.*\.(html|ajax|tpl))$">  
     ForceType application/x-httpd-php  
</FilesMatch>

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

    Increase PHP's Memory Limit

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

    php_value memory_limit 128M

    Viel zu hoch.

    Gruß aus Berlin!
    eddi

    Beitrag melden
    –
    Informationen zu den Bewertungsregeln