Statische Inhalte über Subdomain

[Naps]

Hi,

wenn ich für meine Domain www.example.com eine Subdomain static.example.com anlege, um die Statischen Inhalte auszuliefern, reicht es dann aus diese Subdomain einfach auf www.example.com zu verlinken?

Das heißt ich binde alle Bilder, css, js usw. z.B. über static.example.com/css/style.css ein aber sie liegen eigentlich auf www.example.com/css/style.css.

Mir geht es nur darum um nicht jedes mal die Cookies mitzusenden.

MfG Naps

[Gunnar Bittersmann]

@@Naps:

nuqneH

wenn ich für meine Domain www.example.com eine Subdomain static.example.com anlege, um die Statischen Inhalte auszuliefern, reicht es dann aus diese Subdomain einfach auf www.example.com zu verlinken?

Was meinst du damit?

Das heißt ich binde alle Bilder, css, js usw. z.B. über static.example.com/css/style.css ein aber sie liegen eigentlich auf www.example.com/css/style.css.

?? Soll das übersetzt heißen, www.example.com und static.example.com haben im Dateisystem auf dem Server dasselbe Webroot?

Mir geht es nur darum um nicht jedes mal die Cookies mitzusenden.

Da sollte die Subdomain eine Rolle spielen, nicht das Dateisystem. Für www.example.com werden Cookies mitgesendet, für static.example.com, auch wenn die Dateien auf dem Server im selben Verzeichnis liegen.

Qapla'

[Naps]

?? Soll das übersetzt heißen, www.example.com und static.example.com haben im Dateisystem auf dem Server dasselbe Webroot?

genau ;)

Mir geht es nur darum um nicht jedes mal die Cookies mitzusenden.

Da sollte die Subdomain eine Rolle spielen, nicht das Dateisystem. Für www.example.com werden Cookies mitgesendet, für static.example.com, auch wenn die Dateien auf dem Server im selben Verzeichnis liegen.

Danke, hab da wieder mal zu kompliziert gedacht...

MfG Naps

[Gunther]

@@Gunnar + Naps:

nuqneH

@Gunnar: Ich habe mir deine Antwort jetzt x-mal durchgelesen, werde aber immer noch nicht ganz schlau daraus. ;-)

wenn ich für meine Domain www.example.com eine Subdomain static.example.com anlege, um die Statischen Inhalte auszuliefern, reicht es dann aus diese Subdomain einfach auf www.example.com zu verlinken?

Was meinst du damit?

Hier liegt imho schon der erste Punkt vor, der einer genaueren Erläuterung bedarf.
Verlinken ist hier vielleicht auch nicht ganz der richtige Begriff, denn es ist ja das DocumentRoot Verzeichnis für die Subdomain in der VHost Konfiguration gemeint.

Die Domain ist "example.com".
Und "www.example.com" ist bereits eine Subdomain!
Genauso wie "static.example.com".

Das heißt ich binde alle Bilder, css, js usw. z.B. über static.example.com/css/style.css ein aber sie liegen eigentlich auf www.example.com/css/style.css.

?? Soll das übersetzt heißen, www.example.com und static.example.com haben im Dateisystem auf dem Server dasselbe Webroot?

Soll es wohl heißen.
Das ist dann auch gleich der Nachteil, denn wie im Beispiel schon aufgezeigt, ist die Datei 'style.css' dann unter beiden Adressen erreichbar.

Mir geht es nur darum um nicht jedes mal die Cookies mitzusenden.

Da sollte die Subdomain eine Rolle spielen, nicht das Dateisystem. Für www.example.com werden Cookies mitgesendet, für static.example.com, auch wenn die Dateien auf dem Server im selben Verzeichnis liegen.

Was Gunnar damit sagen will ist, dass wenn du deine Cookies explizit und ausschließlich für die Subdomain "www.example.com" setzt, dann "funktioniert" dein Vorhaben, da diese Cookies dann nicht für Anfragen an "static.example.com" mitgesendet werden (siehe bspw. setcookie Domain-Parameter).

Aber mal abgesehen davon, dass es i.d.R. nicht "wünschenswert" ist, dass zwei verschiedene Subdomains denselben DocumentRoot haben, bzw. eine einen unterhalb der anderen, sehe ich das Hauptproblem bei dem Ansatz darin, dass man die Site explizit unter "www.example.com" erreichbar machen muss.

Und bei Javascript muss man ggf. auch noch auf die Same-origin policy achten.

Alternativ ist es ggf. sinnvoller localStorage anstelle von Cookies zu verwenden. Das hängt aber u.a. von den Informationen ab, die gespeichert werden sollen und wozu sie dienen (wenn eine serverseitige Verarbeitung erforderlich ist, sind Cookies im Vorteil).

Gruß Gunther

[ChrisB]

Hi,

Was Gunnar damit sagen will ist, dass wenn du deine Cookies explizit und ausschließlich für die Subdomain "www.example.com" setzt, dann "funktioniert" dein Vorhaben, da diese Cookies dann nicht für Anfragen an "static.example.com" mitgesendet werden (siehe bspw. setcookie Domain-Parameter).

Aber mal abgesehen davon, dass es i.d.R. nicht "wünschenswert" ist, dass zwei verschiedene Subdomains denselben DocumentRoot haben, bzw. eine einen unterhalb der anderen, sehe ich das Hauptproblem bei dem Ansatz darin, dass man die Site explizit unter "www.example.com" erreichbar machen muss.

Es wäre IMHO wünschenswert gewesen, wenn man es so gelassen hätte, dass der domain-Parameter eines Cookies den führenden Punkt enthalten muss, um auch Subdomains einzuschließen.
Dann könnte man example.com angeben, und die Cookies würden nur dorthin gesendet – und static.example.com bliebe von ihnen unbehelligt.

Warum man das so geändert hat, dass example.com subdomains mit einschließt, erschließt sich mir nicht. Das scheint mir eher einen Nachteil darzustellen.

MfG ChrisB

[molily]

Hallo,

wenn ich für meine Domain www.example.com eine Subdomain static.example.com anlege, um die Statischen Inhalte auszuliefern, reicht es dann aus diese Subdomain einfach auf www.example.com zu verlinken?

Welchen Vorteil soll das bringen?

Asset-Hosts verwendet man, um möglichst viele parallele TCP-Verbindungen zu erlauben und damit das Browser-Limit von 4-8 Verbindungen pro Host zu umgehen. Außerdem ist Load Balancing einfacher, wenn die Assets nicht auf dem Application Server liegen, sondern von einem »dummen« HTTP-Daemon ausgeliefert werden können, wahlweise aus dem Dateisystem oder aus einem Memcache. Es lässt sich sehr schnell ein Content Delivery Network verwenden, falls nötig.

Wenn die Asset-Hostnamen und der Haupt-Hostname auf denselben Server zeigen, müsste die Website schon viele Assets gleichzeitig laden, damit eine bessere Performance erreicht wird. Der Server muss mit den vielen Verbindungen pro Client zurecht kommen.

Parallelisierung sorgt lediglich dafür, dass die zur Verfügung stehende Bandbreite besser ausgenutzt wird. Gerade in High-Latency-Netzwerken (mobile Webzugänge) ergibt es keinen Vorteil, eine hohe Anzahl von nebenläufige TCP-Verbindungen zu öffnen, insbesondere zur selben IP-Adresse. Das bremst das Laden der Website vielmehr aus. Man sollte auch bedenken, dass zusätzliche DNS-Anfragen für die Asset-Hosts nötig sind.

Ob das ganze letztlich schneller ist, muss man schlicht testen.

Mathias

[Gunther]

Hallo Mathias!

wenn ich für meine Domain www.example.com eine Subdomain static.example.com anlege, um die Statischen Inhalte auszuliefern, reicht es dann aus diese Subdomain einfach auf www.example.com zu verlinken?

Welchen Vorteil soll das bringen?

Das ist eine, u.a. von Yahoo "empfohlene" Methode zur Performance-Steigerung für Websites, die Cookies verwenden.

Der Performance-Gewinn soll sich darin äußern, dass der Browser eben nicht bei jedem Request immer den kompletten Inhalt des Cookies mitsendet.

Gruß Gunther