6
Subdomain per htaccess mod rewrite löschen
Hallo zusammen!
Ich habe folgendes Szenario:
1. Ein Webspace mit PHP-Scripten
2. Mehrere Domains welche auf ein und den selben Webspace verweisen
3. Eine Website die
- mehrsprachig ist
- eine dynamische Sprachumschaltung bietet
- ausgiebigen Gebrauch von Browser-Caches machen soll
- ausgiebigen Gebrauch von Rewrite-Rules zur SuMa-Optimierung macht
Mein Problem: Browser-Cache und dynamische Sprachumschaltung machen zusammen Probleme da einige (nicht alle) Browser die HTML-Inhalte der überschriebenen URLs nicht neu laden sondern aus dem Cache holen und zwar immer mit der Sprache die zuerst gewählt war.
Meine Idee: Die Sprachumschaltung so lösen dass die einzelnen Sprachen als Subdomains angelegt sind, z.B.:
http://de.domain.tld/test.html
http://en.domain.tld/test.html
http://fr.domain.tld/test.html
http://de.domain2.tld/test.html
http://en.domain2.tld/test.html
http://fr.domain2.tld/test.html
usw.
So würde der Browser für jede Subdomain einen separaten Cache anlegen. Jetzt müßte ich nur noch mod_rewrite dazu kriegen die jeweilige Sprach-Subdomain undabhängig von der Domain (da es ja mehrere verschiedene gibt) einfach aus der URL zu löschen sodass am Ende nur noch
http://domain.tld/test.html
http://domain2.tld/test.html
usw.
übrig bleiben. Die Erkennung welche Sprache in der URL stand mache ich dann im Nachgang im PHP über $_SERVER['SERVER_NAME'].
Ich habe folgendes Szenario:
1. Ein Webspace mit PHP-Scripten
2. Mehrere Domains welche auf ein und den selben Webspace verweisen
3. Eine Website die
- mehrsprachig ist
- eine dynamische Sprachumschaltung bietet
- ausgiebigen Gebrauch von Browser-Caches machen soll
- ausgiebigen Gebrauch von Rewrite-Rules zur SuMa-Optimierung macht
Mein Problem: Browser-Cache und dynamische Sprachumschaltung machen zusammen Probleme da einige (nicht alle) Browser die HTML-Inhalte der überschriebenen URLs nicht neu laden sondern aus dem Cache holen und zwar immer mit der Sprache die zuerst gewählt war.
Meine Idee: Die Sprachumschaltung so lösen dass die einzelnen Sprachen als Subdomains angelegt sind, z.B.:
http://de.domain.tld/test.html
http://en.domain.tld/test.html
http://fr.domain.tld/test.html
http://de.domain2.tld/test.html
http://en.domain2.tld/test.html
http://fr.domain2.tld/test.html
usw.
So würde der Browser für jede Subdomain einen separaten Cache anlegen. Jetzt müßte ich nur noch mod_rewrite dazu kriegen die jeweilige Sprach-Subdomain undabhängig von der Domain (da es ja mehrere verschiedene gibt) einfach aus der URL zu löschen sodass am Ende nur noch
http://domain.tld/test.html
http://domain2.tld/test.html
usw.
übrig bleiben. Die Erkennung welche Sprache in der URL stand mache ich dann im Nachgang im PHP über $_SERVER['SERVER_NAME'].
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 146851
Url: https://administrator.de/forum/subdomain-per-htaccess-mod-rewrite-loeschen-146851.html
Ausgedruckt am: 14.04.2025 um 01:04 Uhr
6 Kommentare
Neuester Kommentar
Hallo @Codehunter,
kennst du die beiden META-Tags
Möglicherweise können sie dir bei deinem Problem helfen
Gruß
Snow
kennst du die beiden META-Tags
PRAGMA und CACHE-CONTROL?Möglicherweise können sie dir bei deinem Problem helfen
Gruß
Snow
Kenn ich. Nützt aber für sich alleine nichts da wie gesagt je ein Cache pro Sprache angelegt werden muss (liegt in der Natur der Scripte die da laufen)
Moin moin
Bist du dir da sicher ?
Mein Gedanke war das nach dem "umschreiben" der URI diese... eben umgeschrieben ist - die alte nicht mehr da ist !
Ich habe da mal schnell ein bisschen am meiner Config gebastelt:
.htaccess
Der Aufruf von "de.test/codehunter2" wurde auf "test/codehunter2" umgeleitet wo mir "$_SERVER['SERVER_NAME']" den Servernamen: "test" ausgibt !
Und wenn man sich die HTTP-Header ansieht wird auch klar warum:
Und dann wäre da auch noch folgendes:
Ich vermute mal das du die Links in deinem Seiten alle relativ gestaltet hast. Wenn ich nun die englische Version deiner Seite aufrufe "bastelt" mir mein Browser die URL der Links ja aus aufgerufenen URI und dem relativen Pfad aus dem Link zusammen: "http://en.test/"//"shop/artikel-15.html"//. Wenn du das aber nun umschreiben lassen würdest, würde ich anstelle der englischen Subdomain die deutsche Domain im Browser stehen haben ! Und wenn wir nun die Links nochmal zusammen setzten und einen anklicken, landen wir zwar auf der richtigen Seite, aber in der falschen Sprache !
~Arano
... noch mod_rewrite dazu kriegen die jeweilige Sprach-Subdomain ... aus der URL zu löschen ...
Die Erkennung welche Sprache in der URL stand mache ich dann im Nachgang im PHP über $_SERVER['SERVER_NAME'].
Die Erkennung welche Sprache in der URL stand mache ich dann im Nachgang im PHP über $_SERVER['SERVER_NAME'].
Bist du dir da sicher ?
Mein Gedanke war das nach dem "umschreiben" der URI diese... eben umgeschrieben ist - die alte nicht mehr da ist !
Ich habe da mal schnell ein bisschen am meiner Config gebastelt:
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<VirtualHost *:80>
ServerName test
DocumentRoot "/srv/htdocs/test/www"
</VirtualHost>
<VirtualHost *:80>
ServerName de.test
DocumentRoot "/srv/htdocs/test/www"
</VirtualHost>.htaccess
1
2
2
RewriteCond %{SERVER_NAME} ^de
RewriteRule (.*) http://test/codehunter2/$1Der Aufruf von "de.test/codehunter2" wurde auf "test/codehunter2" umgeleitet wo mir "$_SERVER['SERVER_NAME']" den Servernamen: "test" ausgibt !
Und wenn man sich die HTTP-Header ansieht wird auch klar warum:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
http://de.test/codehunter2/
GET /codehunter2/ HTTP/1.1
Host: de.test
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 302 Found
Date: Wed, 14 Jul 2010 08:57:54 GMT
Server: Apache/2.2.14 (Unix)
Location: http://test/codehunter2/
Content-Length: 208
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
----------------------------------------------------------
http://test/codehunter2/
GET /codehunter2/ HTTP/1.1
Host: test
User-Agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
HTTP/1.1 200 OK
Date: Wed, 14 Jul 2010 08:57:54 GMT
Server: Apache/2.2.14 (Unix)
X-Powered-By: PHP/5.3.1
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
----------------------------------------------------------Und dann wäre da auch noch folgendes:
Ich vermute mal das du die Links in deinem Seiten alle relativ gestaltet hast. Wenn ich nun die englische Version deiner Seite aufrufe "bastelt" mir mein Browser die URL der Links ja aus aufgerufenen URI und dem relativen Pfad aus dem Link zusammen: "http://en.test/"//"shop/artikel-15.html"//. Wenn du das aber nun umschreiben lassen würdest, würde ich anstelle der englischen Subdomain die deutsche Domain im Browser stehen haben ! Und wenn wir nun die Links nochmal zusammen setzten und einen anklicken, landen wir zwar auf der richtigen Seite, aber in der falschen Sprache !
~Arano
@Arano:
Das wäre natürlich eine dumme Sache. Da ich das bisher nicht testen konnte weil das Umschreiben der Subdomain bisher nicht funktioniert hat bin ich von der Tatsache ausgegangen, dass umgeschriebene URLs in $_SERVER['REQUEST_URI'] in ihrer Originalform auftauchen, nicht in der umgeschriebenen Form. Dort fehlt aber der Hostname-Anteil und das http:// und ich bin davon ausgegangen daß das Verhalten bei $_SERVER['SERVER_NAME'] äquivalent zu $_SERVER['REQUEST_URI'] wäre.
Was mich jetzt aber wundert: In deinem Fall scheint der Server einen Location-Redirect zu schicken. Bei mir macht das der Apache nicht wenn ich mit mod-rewrite was umschreibe. Dort bleibt der Link in der Browser-Adresszeile so stehen wie eingegeben bzw. angeklickt.
Ansonsten hast du mein Vorhaben vollkommen richtig durchschaut.
Das Kernproblem in meinem Fall ist, dass einige Browser (IE und FF) überhaupt keinen Request mehr an den Server absetzen wenn der Cache-Header vorher eine längere Lebensdauer angegeben hat. Opera verhält sich da schlauer und ruft jedesmal die Resource neu ab, bricht aber nach dem Einlesen des HTTP-Resonse-Header die Verbindung ab wenn der Cache noch gültig ist. IE und FF ignorieren auch die must-revalidate-Anweisung im Cache-Control wenn sie so definiert ist: Cache-Control: max-age=3600, private, must-revalidate
Die Links sind wie du schon sagst alle relativ (bis auf den Sprachumschaltungslink, den WOLLTE ich statisch auf die Subdomain plus dynamisch hinten dran gebastelt den aktuellen REQUEST_URI machen.
Was jetzt aber wahrscheinlich meinen Ansatz komplett begräbt ist die Tatsache dass unser Webhoster keine Wildcard-Subdomains zulässt
Jetzt bleibt mir wohl nur noch, die ganzen Subdomains (Anzahl der Domains multipliziert mit der Anzahl der Sprachen) tatsächlich als VHosts anzulegen *mäh*
EDIT/Korrektur: Opera bricht den Download der Resource nicht ab sondern schickt im Request-Header ein if-modified.since mit was IE und FF nicht tun. Der Server seinerseits ist recht intelligent darin, zu bestimmen ob sich was am Output der Scripte geändert hat oder nicht. Nur was nützt das wenn die Browser diese Infos nicht nutzen? Daran krankt es in meinem Fall. Wenn ich mir überlege was die Konsequenzen sind... IE und FF laden jedesmal die ganze Seite inkl. aller CSS-, JS-, PNG und sonstwas-Dateien nach. Das ist ne Menge unnützer Traffic und ich geh mal schwer davon aus daß dieses Problem nicht nur mich ganz allein auf der Welt betrifft.
Dieser Bug ist zumindest beim IE uralt: http://support.microsoft.com/kb/q217196/ und bis heute (getestet mit voll gepatchtem IE8) nicht gefixt.
EDIT: Fazit: Mein ursprünglicher Ansatz, das ganze über Subdomains zu lösen funktioniert tatsächlich. Der Internet Explorer bildet für jede Subdomain einen separaten Cache. Dadurch kann man alles schön cachen lassen und die dynamische Sprachumschaltung funktioniert auch sauber. Die Ladezeiten pro Pagehit haben sich schön verbessert. Ich denke mal das wird sich auch im Traffic niederschlagen am Monatsende
Die Eingangsfrage nach dem Überschreiben der Subdomains hat sich (leider) erledigt wegen oben erwähnter fehlender Wildcard-Fähigkeit des Webspace.
Damit wäre eine lange lange Baustelle auf unserer Firmenwebsite endlich beseitigt. Ich hatte immer die Wahl zwischen funktionierendem Browsercache und defekter Sprachumschaltung in IE und FF oder aber langsamer Website in allen Browsern und funktionierender Sprachumschaltung.
Das wäre natürlich eine dumme Sache. Da ich das bisher nicht testen konnte weil das Umschreiben der Subdomain bisher nicht funktioniert hat bin ich von der Tatsache ausgegangen, dass umgeschriebene URLs in $_SERVER['REQUEST_URI'] in ihrer Originalform auftauchen, nicht in der umgeschriebenen Form. Dort fehlt aber der Hostname-Anteil und das http:// und ich bin davon ausgegangen daß das Verhalten bei $_SERVER['SERVER_NAME'] äquivalent zu $_SERVER['REQUEST_URI'] wäre.
Was mich jetzt aber wundert: In deinem Fall scheint der Server einen Location-Redirect zu schicken. Bei mir macht das der Apache nicht wenn ich mit mod-rewrite was umschreibe. Dort bleibt der Link in der Browser-Adresszeile so stehen wie eingegeben bzw. angeklickt.
Ansonsten hast du mein Vorhaben vollkommen richtig durchschaut.
Das Kernproblem in meinem Fall ist, dass einige Browser (IE und FF) überhaupt keinen Request mehr an den Server absetzen wenn der Cache-Header vorher eine längere Lebensdauer angegeben hat. Opera verhält sich da schlauer und ruft jedesmal die Resource neu ab, bricht aber nach dem Einlesen des HTTP-Resonse-Header die Verbindung ab wenn der Cache noch gültig ist. IE und FF ignorieren auch die must-revalidate-Anweisung im Cache-Control wenn sie so definiert ist: Cache-Control: max-age=3600, private, must-revalidate
Die Links sind wie du schon sagst alle relativ (bis auf den Sprachumschaltungslink, den WOLLTE ich statisch auf die Subdomain plus dynamisch hinten dran gebastelt den aktuellen REQUEST_URI machen.
Was jetzt aber wahrscheinlich meinen Ansatz komplett begräbt ist die Tatsache dass unser Webhoster keine Wildcard-Subdomains zulässt
Jetzt bleibt mir wohl nur noch, die ganzen Subdomains (Anzahl der Domains multipliziert mit der Anzahl der Sprachen) tatsächlich als VHosts anzulegen *mäh*EDIT/Korrektur: Opera bricht den Download der Resource nicht ab sondern schickt im Request-Header ein if-modified.since mit was IE und FF nicht tun. Der Server seinerseits ist recht intelligent darin, zu bestimmen ob sich was am Output der Scripte geändert hat oder nicht. Nur was nützt das wenn die Browser diese Infos nicht nutzen? Daran krankt es in meinem Fall. Wenn ich mir überlege was die Konsequenzen sind... IE und FF laden jedesmal die ganze Seite inkl. aller CSS-, JS-, PNG und sonstwas-Dateien nach. Das ist ne Menge unnützer Traffic und ich geh mal schwer davon aus daß dieses Problem nicht nur mich ganz allein auf der Welt betrifft.
Dieser Bug ist zumindest beim IE uralt: http://support.microsoft.com/kb/q217196/ und bis heute (getestet mit voll gepatchtem IE8) nicht gefixt.
EDIT: Fazit: Mein ursprünglicher Ansatz, das ganze über Subdomains zu lösen funktioniert tatsächlich. Der Internet Explorer bildet für jede Subdomain einen separaten Cache. Dadurch kann man alles schön cachen lassen und die dynamische Sprachumschaltung funktioniert auch sauber. Die Ladezeiten pro Pagehit haben sich schön verbessert. Ich denke mal das wird sich auch im Traffic niederschlagen am Monatsende
Die Eingangsfrage nach dem Überschreiben der Subdomains hat sich (leider) erledigt wegen oben erwähnter fehlender Wildcard-Fähigkeit des Webspace.Damit wäre eine lange lange Baustelle auf unserer Firmenwebsite endlich beseitigt. Ich hatte immer die Wahl zwischen funktionierendem Browsercache und defekter Sprachumschaltung in IE und FF oder aber langsamer Website in allen Browsern und funktionierender Sprachumschaltung.
Nabend
...vermutung ... recherche ... treffer !
Fertig !?
~Arano
Was mich jetzt aber wundert: In deinem Fall scheint der Server einen Location-Redirect zu schicken. Bei mir macht das der Apache nicht wenn ich mit mod-rewrite was umschreibe. Dort bleibt der Link in der Browser-Adresszeile so stehen wie eingegeben bzw. angeklickt.
...vermutung ... recherche ... treffer !
Zitat von http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
The Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern. The Substitution may be a:
...
Absolute URL
If an absolute URL is specified, mod_rewrite checks to see whether the hostname matches the current host. If it does, the scheme and hostname are stripped out and the resulting path is treated as a URL-path. Otherwise, an external redirect is performed for the given URL. To force an external redirect back to the current host, see the [R] flag below.
...
The Substitution of a rewrite rule is the string that replaces the original URL-path that was matched by Pattern. The Substitution may be a:
...
Absolute URL
If an absolute URL is specified, mod_rewrite checks to see whether the hostname matches the current host. If it does, the scheme and hostname are stripped out and the resulting path is treated as a URL-path. Otherwise, an external redirect is performed for the given URL. To force an external redirect back to the current host, see the [R] flag below.
...
Fertig !?
~Arano
Ok damit erklärt sich sowohl das Verhalten bei mir als auch bei dir Wie gesagt, das Subdomain-Umschreiben hat bei mir ja nie funktioniert, darum konnte ich ja nur Vermuten...
Aber zumindest mein Anstz der getrennten Browser-Caches durch Subdomains funktioniert super. Wenn ich auch die Dinger alle händisch anlegen musste wegen fehlender Wildcards.
Ich würd mal sagen, Problem gelöst Thx!
Wie gesagt, das Subdomain-Umschreiben hat bei mir ja nie funktioniert, darum konnte ich ja nur Vermuten...Aber zumindest mein Anstz der getrennten Browser-Caches durch Subdomains funktioniert super. Wenn ich auch die Dinger alle händisch anlegen musste wegen fehlender Wildcards.
Ich würd mal sagen, Problem gelöst
Thx!
