Styleguide:Techn. Integration via Durchschleifung: Unterschied zwischen den Versionen

Aus Imperia Support Wiki
K (Technische Voraussetzungen)
K (Hinweise HTTPS-Requests)
 
Zeile 52: Zeile 52:
 
==== Hinweise HTTPS-Requests ====
 
==== Hinweise HTTPS-Requests ====
  
* Die Requests werden von apache [[mod_proxy_http:https://httpd.apache.org/docs/2.4/en/mod/mod_proxy_http.html]] bzw. [[mod_proxy:https://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html]] generiert.
+
* Die Requests werden von apache [https://httpd.apache.org/docs/2.4/en/mod/mod_proxy_http.html mod_proxy_http] bzw. [https://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html mod_proxy] generiert.
 
* Alle Requests müssen unter 5 Sekunden beantwortet werden.
 
* Alle Requests müssen unter 5 Sekunden beantwortet werden.
 
* Cookies werden standardmäßig nicht an die Applikation durchgereicht. Unter Angabe der Cookie-Namen können Ausnahmen eingerichtet werden. (siehe oben)
 
* Cookies werden standardmäßig nicht an die Applikation durchgereicht. Unter Angabe der Cookie-Namen können Ausnahmen eingerichtet werden. (siehe oben)

Aktuelle Version vom 4. Januar 2021, 15:53 Uhr

Berlin.de / BerlinOnline stellt die Möglichkeit zur Verfügung Angebote für einen geschlossenen URL Bereich direkt von einem externen Server einzubinden. Dies wird technisch über ein eigenständiges Backend im Varnish HTTP Cache gelöst.

Funktion

Technisch funktioniert das wie folgt:

  • Ein WWW-Browser fragt eine URL bei www.berlin.de an
  • Im Varnish HTTP Cache wird für diesen HTTP-Request geprüft, ob gültiger zwischengespeicherter Inhalt verfügbar ist und liefert gegebenenfalls diesen zurück
  • Varnish HTTP Cache leitet den Request an den Server der Applikation weiter. Im Normalfall wird der Request dabei nicht verändert. Es werden lediglich die Cookies gefiltert.
  • Der Server der Applikation antwortet mit einer kompletten Seite, die im Varnish HTTP Cache zwischengespeichert wird, wenn das möglich ist.
  • Das Portallayout von Berlin.de wird über die Auswertung von Edge Side Includes in die Seite eingefügt
  • Der Varnish HTTP Cache anwortet mit dem jetzt vollständigen Inhalt dem WWW-Browser

Vorgehen

Integration des Portallayouts

Das Portal-Layout besteht aus drei HTML Teilen die an bestimmten Stellen einzufügen sind. Beispielhaft für ein Anwendung die unter www.berlin.de/rbmskzl/aktuelles/ liegt:

Die allgemeine Seitenstruktur sieht damit in etwa so aus:

<!doctype html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
    <meta charset="UTF-8"/>
    <title>…</title>
    <esi:include src="/rbmskzl/aktuelles/__i9/std/head.inc" />
</head>
<body>
    <esi:include src="/rbmskzl/aktuelles/__i9/std/top.inc" />
    …
    <esi:include src="/rbmskzl/aktuelles/__i9/std/foot.inc" />
</body>

Technische Voraussetzungen

  • Das HTML Markup der Applikation entspricht dem oben stehenden Beispiel
  • Als Seitenkodierung folgt dem UTF-8 Standard
  • Alle in der Applikation verwendeten Resourcen befinden sich unterhalb des Pfades der Applikation. Für dieses Beispiel, unterhalb von /rbmskzl/aktuelles/
  • Die Applikation ist direkt vom Varnish HTTP Cache erreichbar. Dabei ist die Applikation unter dem Virtual-Hostnamen www.berlin.de, stg.berlin.de, test.berlin.de unter dem einzubindenen Pfad erreichbar.
  • Die Applikation stellt eine URL für einen HEALTH-Check durch den Varnish zur Verfügung.
  • Die Applikation beantwortet typische Requests unter einer Sekunde bis in Ausnahmen fünf Sekunden
  • Die Inhalte entsprechen den Berlin.de Styleguides
  • Die Inhalte sollten zwischenspeicherbar sein und anderenfalls das Zwischenspeichern mittels Cache-Control steuern
  • Alle durch die Applikation serverseitig benutzten Cookies müssen bekannt gegeben werden. Dabei sollten die Cookie-Namen applikationsspezifisch sein. Allgemeine Cookies, wie PHPSESSID und ähnliches sind unzulässig. Cookies sollten nur für den Pfad der Applikation gültig sein.

Hinweise HTTPS-Requests

  • Die Requests werden von apache mod_proxy_http bzw. mod_proxy generiert.
  • Alle Requests müssen unter 5 Sekunden beantwortet werden.
  • Cookies werden standardmäßig nicht an die Applikation durchgereicht. Unter Angabe der Cookie-Namen können Ausnahmen eingerichtet werden. (siehe oben)
  • Es werden zusätzliche Request-Header bereitgestellt:
    • X-Forwarded-Host – DNS Name des Portals, als Ersatz für den Host-Header
    • X-Forwarded-Path – Request Pfad (REQUEST_URI)
    • X-Forwarded-Port – Server-Portnummer (normalerweise 443 für HTTPS, vom varnish gesetzt)
    • X-Forwarded-Proto – Protokollname (normalerweise https, vom varnish gesetzt)
    • X-Host – DNS Name des Portals, als Ersatz für den Host-Header (veraltet, nicht nutzen)
    • X-Offer – Request Pfad (REQUEST_URI)
    • X-Portal – DNS Name des Portals, als Ersatz für den Host-Header
    • X-ServerName – DNS Name des Portals, als Ersatz für den Host-Header (veraltet, nicht nutzen)
    • X-SSL – yes wenn eine TLS Verbindung genutzt wurde (vom varnish gesetzt)
  • Die meisten anderen Header werden ein-zu-eins beim Request und der Response weitergeleitet.
  • Header die hier nicht erwähnt werden sind unzuverlässlich und sollten daher nicht genutzt werden.
  • Durch die mehrfache Weiterleitung der Requests, sind Applikationen über diesen Weg langsamer und weniger zuverlässig.

Layout

Bei der Layoutanpassung sind folgende Informationen für Sie wichtig:

  • Das Berlin.de Layout basiert auf Twitter Bootstrap 2.3.
  • Bitte konsultieren Sie den Styleguide für das Portal
  • Definieren Sie keine globalen CSS-Regeln, sondern wickeln Sie ggf. um Ihre Inhalte einen identifizierbaren Container, wie z.B. <div id="partner"></div>, und gestalten Sie Ihre CSS-Angaben entsprechend: #partner a {color:blue;}</div>.