HTML

Diese Seite erklärt in knapper Form die Ideen von HTTP, HTML, CSS, JS.

Inhalt

Browseranfrage

Du betrachtest die aktuelle Seite in einem Browser. Ein Web-Browser ist ein lokal auf deinem (Windows-)Rechner installiertes Programm. Wenn man oben in der URL-Zeile einen Namen eingibt, versucht der Browser eine Datei (genauer gesagt: eine „Resource“) mit diesem Name zu finden.

Was vom Server zurück kommt

Oft wird es sich bei der Server-Antwort um den Inhalt einer Datei im HTML-Format handeln, die Text enthält, welcher angezeigt werden soll.

Sie kann zusätzlich auch Verweise auf weitere Ressourcen enthalten, wie etwa auf Style-Anweisungen (CSS-Dateien), Fonts (WOFF) oder anzuzeigende Bilder (JPG,PNG), auf Sound (MP3,OGG) oder Videos (MP4,WEBM) oder auch auf Programm-Code (JS), den der Browser ausführen soll. Wenn du eine „einzelne Seite“ im Web aufrufst, kann es ohne weiteres passieren, dass der Browser sich 30 mal mit dem Server unterhält, bevor die Seite fertig aufgebaut ist. Es kann sogar sein, dass er zwischendurch auch Inhalte von anderen Servern herbeiholt, weil in der ursprünglichen Antwort des angesprochenen Servers darum gebeten wird. Damit auf diese Weise nicht zu viel „Unfug“ getrieben wird, haben die Browser bestimmte Sicherheitsrichtlinien (CORS).

Die vielen Anfragen, die beim Aufbau einer Seite im Hintergrund passieren, laufen übrigens asynchron, d.h. der Browser stellt gleichzeitig viele Anfragen (z.B. nach allen Bildern, die auf der Seite gezeigt werden sollen) und bekommt die Antworten dann zeitlich versetzt und ungeordnet. Er muss alles richtig zusammenführen. Damit der Benutzer nicht warten muss, bis die letzte Antwort eingetroffen ist, baut der Browser den Bildschirm auf der Basis von Teilantworten auf und baut ihn später um, nachdem weitere Informationen eingetroffen sind.

Jeder Browser besitzt einen Debugger. Den solltest du unbedingt kennenlernen. Klicke rechts auf irgendein Element des Browser-Fensters und wähle „Untersuchen“ aus (in Google Chrome, bei anderen Browser ist es ähnlich). Betrachte alle Tabs (Reiter, Laschen), insbesondere den Network-Tab. Damit du siehst was beim Laden einer Seite passiert, musst du die Seite im Browser erneut laden, während der Debugger offen ist. Schau dir auch den HTML-Code an, JSON Responses, JS-Code und Cookies.

Rendering

Die Hauptaufgabe des Browsers besteht darin, den Text und die Bilder darzustellen. Das nennt man „Rendering“. Beim Rendering beachtet der Browser die HTML-Anweisungen („Tags“ zwischen spitzen Klammern), welche die Formatierung („Layout“,“Style“) festlegen (Schriftart, Größe, Fettdruck, Einrückungen, Farben, Abstände, Trennlinien, Fußnoten usw.). Damit der eigentliche inhaltliche Text und die vielen Layout-Hinweise sich nicht zu sehr vermischen, lagert man das Styling gern in separate Abschnitte der HTML-Datei oder gar in separate CSS-Dateien aus.

Programmausführung im Browser

Wenn der Browser in den Server-Antworten neben manchen anderen Dingen auch Javascript-Code (JS) erhalten hat, wird er diesen ausführen. Dabei kann er zu beliebigen Zeitpunkten – auch ohne dass du etwas dazu tust oder es bemerkst – weitere Anfragen an den Server richten. Oft erhält er dabei eine Antwort im JSON-Format. Dieses Datenformat wird zwar auch via HTTP transportiert, ist aber für den Nachrichtenaustausch zwischen zwei Programmen gedacht und daher für den Menschen nur bedingt lesbar. Solche Nachrichten werden in der Regel dem Nutzer auch nicht direkt angezeigt.
Ein Beispiel: Wenn du in einem Formular auf einer Website eine Postleitzahl eingibst, besorgt sich der Browser eine Liste der dazu passenden Städtenamen vom Server, nachdem du die Ziffern eingegeben hast. Es wäre höchst unpraktisch, wenn der Server dem Browser eine Liste aller Städte vorab mitteilen würde. Der Browser füllt daraufhin das Feld mit dem Ortsnamen. An der Reaktion des Browsers kannst du erkennen, dass er im Hintergrund etwas getan hat. Wenn du dann noch die Straße und die Hausnummer eingibst, kann es sein, dass der Browser nochmals den Server fragt, um herauszufinden, ob Personen mit dieser Wohnadresse voraussichtlich ihre Rechnung bezahlen werden (Bonität). Darüber wird dich der Browser normalerweise nicht informieren. Wenn du dann aber etwas bestellen willst und die Bonität wurde vom Server als gering eingeschätzt, dann erlaubt dir der Browser bei der Auswahl der Zahlungsbedingungen jedoch nur „Vorkasse“ und „per Nachnahme“.

Internet – Nachrichtenverkehr

Alle Nachrichten, die über das Web ausgetauscht werden, sind im Prinzip technisch zugänglich, wenn man sich damit auskennt. Allerdings werden alle Nachrichten in kleine Portionen („Pakete“) zerhackt und nehmen häufig sogar unterschiedliche Wege, wenn sie von einer IP-Adresse A zu einer IP-Adresse B übertragen werden. Dabei gerät auch die Reihenfolge durcheinander (Laufzeitunterschiede). Der Empfänger muss also alle Pakete wieder zusammensetzen; verloren gegangene Pakete erkennt er und fordert sie erneut an.

Wenn jemand technisch viel weiß, kann er dennoch als „man in the middle“ alle Pakete abfangen und deren Inhalt verändern, ohne dass es A oder B mitbekommen. Um sich dagegen zu schützen, können Sender und Empfänger Verfahren zur Datenverschlüsselung benutzen, Außerdem wollen sie natürlich wissen, ob sie wirklich mit dem gewollten Partner reden oder mit einem verborgenen Mittelsmann.

HTTP-Nachrichten beruhen ursprünglich immer darauf, dass der Client die Initiative ergreift und den Server etwas fragt und dass dieser dann antwortet. Der Browser überwacht die Zeitdauer und meldet „nicht verfügbar“, wenn die Antwort zu lange dauert.
Es gibt jedoch seit einiger Zeit auch diverse Mechanismen, über die ein Server von sich aus dem Client etwas mitteilen kann (push-Nachrichten, Websockets, Long Polling, usw.). Oft ist dies aus Sicht des Benutzers lästig, manchmal aber auch erwünscht (Börsenkursticker alle 10 Sekunden). Die einfachste Art des „Zusendens“ besteht darin, dass der Browser per JS regelmäßig Update-Requests an den Server schickt und daraufhin den Bildschirminhalt aktualisiert.

Die URL (uniform resource locator)

Doch zurück zur Anfrage, die man in das URL-Feld einträgt:

  • Beginnt der Name mit file:// , dann sucht der Browser nach einer Datei auf der lokalen Festplatte.
  • Beginnt der Name mit http://localhost , dann fragt der Browser einen HTTP-Server, der sich auf dem eigenen Rechner befinden muss; das klappt natürlich nur, wenn ein solcher Server installiert ist (z.B. mit xampp)
  • Beginnt die URL mit Zahlen, die eine IP-Adresse darstellen, so wendet sich der Browser direkt an diese Adresse. Befindest du dich in einem LAN, dessen IP-Adressbereich mit 192.168.xxx.xxx beginnt, so kannst du auf diese Weise HTTP-Server erreichen, die sich auf anderen Rechnern in deinem LAN befinden.
  • Zu einer http:// – Anfrage gehört immer auch eine Portnummer, die mit einem Doppelpunkt abgetrennt ist. Allerdings kann man diese Nummer weglassen, wenn man den Standard-Port für HTTP-Anfragen (:80) meint.
    Wenn man einen Server installiert, muss man den Port festlegen, auf dem er lauscht und antwortet. Wählt man z.B. 9000 aus, so kann man diesen lokalen Server unter http://localhost:9000 erreichen. Auf diese Weise kann man auf einem Rechner auch mehrere Server installieren, solange sie auf unterschiedlichen Ports sitzen.
  • Steht hinter http:// eine Domainbezeichnung (also z.B. „faz.net“), so wendet sich der Browser an einen Nameserver im Internet (wo dieser zu finden ist, steht in der Netzwerkkonfiguration deines Rechners) und erhält von diesem die zugeordnete IP-Adresse.
  • Damit der Benutzer sicher sein kann, dass er auch wirklich mit dem Server spricht, dessen Name er angegeben hat, gibt es eine Hierarchie des Vertrauens, die auf Zertifikaten beruht. Verwendet man https anstelle von http in der URL-Anfrage, dann benutzen Browser und Server andere Ports (:443) und verständigen sich durch den Austausch von Zusatzinformationen über die Authentifikation. Der Datenverkehr zwischen Browser und Server ist dann verschlüsselt, so dass ihn ein fremder Lauscher im Netz nicht entziffern kann.
  • Es kann sein, dass mehrere unterschiedliche Domains auf dieselbe IP-Adresse zeigen.
  • Wenn man in der Browser-Zeile nur die Domain oder nur eine IP-Adresse angibt, antwortet der Server mit einer Standarddatei, die „index.php“ oder „index.html“ heißt. Er sucht diese Datei in seinem Web-Root-Verzeichnis, das oft aus Sicht des lokalen Dateisystems auf dem Server „www“ oder „htdocs“ heißt.
  • Wenn man hinter dem Domainnamen einen Pfad und/oder einen Dateinamen angibt, dann sucht der Server diesen Pfad (relativ zu seiner Web-Root).
  • Wenn ein Dateiname auf html, png, jpg usw. endet, liefert der Server die entsprechende Datei aus („statisches HTML“).
  • Wenn ein Dateiname auf php endet, dann startet der Server den php-Interpreter (also ein Programm, das auf dem Server installiert ist) und bietet ihn, die Anweisungen in der betreffenden php-Datei auszuführen. Bei der Ausführung der Anweisungen erzeugt der php-Interpreter dann HTML-Code („dynamisches HTML“), den der Server an den Browser als Antwort zurückgibt.
  • Wenn man eine php-Datei vom Browser aus anspricht, kann man an die URL ein „?“ anhängen und dahinter Parameter angeben, die der Server liest und an das php-Programm weitergibt. Auf diese Weise kann das php-Programm unterschiedliche Antworten erzeugen, abhängig von den Parameter-Inhalten. Es gibt sogar eine Möglichkeit, Verweise auf Dateien im eigenen Dateisystem als Parameter anzuhängen. In diesem Fall überträgt der Browser den Inhalt dieser Dateien zusammen mit der URL als Anhang zu der URL-Anfrage. Der Server kann solche Dateien dann in seinem eigenen Dateisystem abspeichern, verändern und beliebig weiter verwenden.
  • Wenn man an eine URL ein „#“ (Hash-Tag) und einen Text anhängt, dann betrachtet der Browser den Teil hinter dem # als Hinweis darauf, zu welchem Textteil der Benutzer springen möchte, nachdem die HTML-Antwort des Servers empfangen und dargestellt (gerendert) wurde. Damit das klappt, muss der HTML-Text eine Markierung mit dem betreffenden Namen enthalten.

Es lohnt sich, wenn du einmal die Regeln für den Aufbau einer URL genau studierst.

Daten speichern auf dem Server

Wenn man Daten in eine Webseite einträgt, kann der Browser sie (hoffentlich per https verschlüsselt) an den Server übertragen.
Er spricht dazu auf dem Server häufig ein php-Script an (es funktioniert aber auch mit Java-Programmen und etlichen anderen Technologien).

Das php-Programm auf dem Server prüft die Daten und speichert sie in einer Datenbank, die sich auf dem Server (oder auf einem separaten Rechner innerhalb des Server-Netzwerks) befindet.

Wenn der Benutzer sich Tage später wieder auf dieser Webseite anmeldet, kann ihm der Server „seine“ Daten (z.B. sein Benutzerprofil) wieder zeigen, indem ein anderes php Script den Namen des Benutzers vom Browser bekommt und die gespeicherten Daten aus der Datenbank abruft und dem Browser als JSON oder HTML als Antwort zusendet.

Das php-Script kann die Daten als JSON-Nachricht an den Browser übertragen oder direkt als HTML.

Daten speichern im Browser

Wenn Menschen „anonym“ eine Website besuchen und z.B. einen Warenkorb zusammenstellen, ohne dann am Ende wirklich einzukaufen,
dann möchte der Betreiber der Webseite sie gerne wieder mit diesem Warenkorb konfrontieren, wenn die Benutzer Tage später die betreffende Seite noch einmal aufrufen.
Dazu hinterlegt ein JS-Programm, das von der Website als Antwort auf die erste http-Anfrage übermittelt wurde, bestimmte Daten im Browser (unter dem Namen ihrer URL), z.B. eine Referenznummer. Gleichzeitig wird auf dem Server unter dieser Referenznummer der Warenkorb in der Datenbank gespeichert.
Wenn nun der Benutzer mit demselben Endgerät die Seite erneut besucht, prüft der JS-Code im Browser, ob bereits ein Cookie mit einer Referenznummer hinterlegt ist und fordert ggf. beim Server den Warenkorb an. Auch Spracheinstellungen und etliches andere kann man in Cookies hinterlegen.

Reisebüros benutzen manchmal diese Verfahren, um zu prüfen, ob ein Kunde sich mehrfach für dieselbe Reise interessiert – ohne jedoch zu buchen. Manchmal setzen sie dann die Preise etwas höher an bei späteren Besuchen, um den Kaufdruck zu erhöhen.

Wenn man sich von einem anderen Endgerät aus anmeldet und exakt dieselbe Reise abfragt, sieht man einen niedrigeren Preis.

Der JS-Code einer Website kann auch versuchen, noch zusätzliche Daten über den Nutzer herauszufinden, etwa indem er nach der Browser-Version fragt oder indem er einen kleinen Benchmark durchführt, um die Leistungsfähigkeit des Rechners zu ermitteln. Gewinnt er den Eindruck, dass der Benutzer an einem modernen (teuren) Rechner sitzt, kann er ihm hochwertige Reisen bevorzugt vorschlagen.

Damit eine Website nicht deinen Rechner vollständig ausspähen kann, benutzen die Browser ein „Sandbox“ Konzept, d.h der JS-Code im Browser kommt nicht an das Dateisystem deines Rechners heran.

Batch-Requests, Spidering, SEO

Anstatt einen Browser zu benutzen, kann man einen http-Request auch mit einem Kommandozeilenwerkzeug wie wget oder curl absetzen. Man kann curl-Aufrufe auch in ein lokal ausgeführtes php-Script einbinden. Auf diese Weise könnte man z.B. 10 Nachrichtenportale abfragen und dann per Programm in den erhaltenen Antworten nach irgendeinem Stichwort suchen und den Textabschnitt anzeigen, in dem das Stichwort vorkommt.

So etwas erfordert viel Programmieraufwand, aber es hat den Vorteil, dass es vollständig automatisierbar ist. Man könnte z.B. versuchen, auf diese Weise das aktuelle Kinoprogramm aller Kinos einer bestimmten Region zusammenzufassen. Dazu muss das Programm, welches die vielen Seiten abfragt, am Ende selbst auch wieder eine HTML-Seite erstellen. Oder besser: Es trägt seine Ergebnisse in eine Datenbank ein und ein anderes Programm (das dann eigentlich wieder ein Web-Server ist), gestattet Benutzern über URL-Requests den Zugriff auf den Datenbankinhalt.

Wenn man sich direkt mit dem HTML-Code jeder Seite auseinandersetzen muss, ist das sehr, sehr mühsam und fehleranfällig; man hat sich daher darauf verständigt, dass Webseiten „Feeds“ anbieten können, in denen sie „Nettoinformationen“ in strukturierter Form anbieten und aktualisieren.

Damit Google Suchergebnisse liefern kann, muss Google so viele Webseiten wie möglich untersuchen und interessante Suchbegriffe darin herausfiltern. Damit das möglichst effektiv geht, kann man in HTML im Kopfbereich spezielle Tags benutzen, bei denen man Stichworte zum Inhalt der Seite hinterlegt. Man optimiert die Seite auf diese Weise für Google und anderer Search Engines (SEO = Search Engine Optimization).

Wenn die Google-Indexer in einer HTML-Antwort eines beliebigen Servers Verweise auf andere Seiten („Hyperlinks“, Verweise auf Bilder usw.) finden, dann hangeln sie sich sozusagen an Spinnenfäden durch das Web entlang; die Indizierprogramme von Suchmaschinen heißen daher auch „spider“. Nebenbei halten sie auch noch fest, wie viele Webseiten (A,B,C, ..) einen Verweis auf eine bestimmte andere Webseite (X) enthalten. Je öfter X vorkommt, desto populärer scheint X zu sein und desto weiter oben in der Trefferliste von Google kommt es vor. Wenn A oder C ihrerseits als populär gelten, dann steigert das den Wert eines Verweises auf X zusätzlich. Wenn zwei Seiten (U,V) sich gegenseitig verlinken, dann steigert das ihre Popularität nur minimal. Wenn allerdings U sehr populär ist, dann steigert der Verweis von U auf V die Popularität von V merklich. Wenn der Inhaber von „Z“ viel Geld an Google bezahlt, kann er weiter oben in der Trefferliste stehen, als es seinem Ranking aufgrund der Wertschätzung aus der Sicht anderer Webseiten entsprechen würde.

Wenn man eine Zeitung im Internet liest, dann wird oft „passende“ Werbung eingeblendet. Da Google die Suchhistorie eines Rechners (Browsers) speichert, kann es einer beliebigen Website passende Links auf Dinge anbieten, die der Benutzer in den letzten Wochen gesucht hat. Manchmal funktioniert so etwas, manchmal wirkt es aus Benutzersicht etwas dümmlich, nämlich wenn man bereits eine Kaufentscheidung getroffen hat. Aber soll man sich wirklich wünschen, dass Google auch das noch im Detail nachvollziehen kann?

Javascript ohne Browser

Traditionell ist Javascript die „Programmiersprache für den Browser“. JS hat übrigens überhaupt nichts mit der klassischen Programmiersprache Java zu tun, obwohl der Name so ähnlich klingt.

Web-Entwickler müssen neben HTML, CSS und JS häufig auch php verstehen und schreiben können, weil auf dem Server (Unix-Betriebssystem) traditionell ganz andere Sprachen etabliert sind (php, python, perl, Java, Ruby, tcl/tk). Aus dem „Bruch zwischen den Sprachen“ ergeben sich zahlreiche Mühseligkeiten, zumal für die Kommunikation mit der Datenbank auf dem Server noch eine weitere Sprache (SQL) hinzukommt.

Ein erster Versuch der Standardisierung bestand darin, Daten zwischen php (Server) und JS (Browser, Client) im sog. XML Format zu übertragen. Dieses Format ist sehr gründlich entworfen, für viele praktische Fälle abr recht schwerfällig und geschwätzig. Wenn man „strict“ HTML benutzt, dann ist auch HTML ein XML-Dokument, d.h. XML benutzt spitze Klammern, um „Tags“ in die Daten einzubetten, aus denen die Bedeutung der Textinhalte hervorgeht.

Besser geeignet is die Javascript Object Notation (JSON); sie ist schlanker und hat den Vorteil, dass sie ohnehin organischer Bestandteil von JS ist. Also haben alle Serversprachen gelernt, JSON-Nachrichten zu empfangen, zu analysieren, in ihr eigenes Format zu übersetzen und ihre Ergebnisse bei Bedarf auch als JSON auszugeben (außer sie produzieren HTML/XML als Ergebnis).

Irgendwann kam jemand auf die Idee, den Javascript-Interpreter aus dem Browser herauszuholen und als eigenständige Programmiersprache auch auf dem Server zu benutzen. Dieser Ansatz ist als Node.js bekannt (manchmal auch als NodeJS geschrieben). Node.js wurde anfangs belächelt, weil die Programme etwas langsamer liefen als die anderen Server-Programme. Inzwischen ist es aber ein ernst zu nehmender Weg, der den großen Vorteil hat, dass man auf dem Client und auf dem Server mit derselben Programmiersprache arbeiten kann.

Fehlertoleranz, Syntax

HTML war am Anfang „schnell zusammengestrickt“ und nicht besonders sorgfältig definiert als Sprache. Außerdem haben viele Leute mit normalen Texteditoren HTML geschrieben und dabei auch Fehler gemacht, z.B. schließende Tags vergessen.

Die Hersteller der Browser haben daraufhin ihren Browsern beigebracht, auch „völlig kaputte“ Syntax noch zu akzeptieren und irgendetwas halbwegs vernünftiges anzuzeigen, selbst wenn so elementare Tags wie <html> oder <body> fehlen oder mehrfach vorkommen.

Deshalb Können wir z.B. einfach „Hallo Welt“ in eine Datei schreiben und die Browser werden den Text anzeigen, obwohl <html> und <body> fehlen.

Später hat man HTML5 als eine XML-konforme Sprache definiert und wesentlich mehr Klarheit geschaffen und Mehrdeutigkeiten entfernt. Man kann Webseiten auf Einhaltung alle HTML5-Regeln prüfen lassen, bevor man sie ins Netz stellt.

Die gängigen Content-Management-Systeme erzeugen korrektes HTML5.

Content-Management-Systeme

Als das Web zum Massenphänomen wurde, musste man einfache Möglichkeiten schaffen, eine Website zu erstellen. Man konnte nicht erwarten, dass jeder HTML lernt, der etwas publizieren will.

Also entwarf man Web-Anwendungen, die dazu dienen, ihrerseits andere Webanwendungen zu bauen. Diese Gattung von Anwendungen nennt man CMS (Content Management Systeme). Sie bieten für eine Administrator die Möglichkeit, das generelle Layout einer Website einzustellen. Für ander Personen, die Content-Lieferanten (Editoren), hat man die Möglichkeit geschaffen, ihrer fachlichen Inhalte in das System zu packen, ohne sich viel mit Technik befassen zu müssen. Die meisten CMS erlauben es dem Benutzer jedoch auch, in Sonderfällen direkt HTML einzugeben.

Ein CMS ist meist in php geschrieben und legt seine Daten (also die Inhalte der zu erstellenden Website) in einer Datenbank ab. Wenn ein Endbenutzer der erstellten Website diese aufruft, wird der HTML Code, den ihm das System zeigt, dadurch montiert, dass die passenden Teile aus dieser Datenbank herausgeholt werden.

Viele CMS bieten die Möglichkeit „Plugins“ zu installieren, also kleinere (oder größere) funktionale Erweiterungen, die nicht von Hersteller des CMS entwickelt wurden, sondern von unabhängigen Dritten. Manche Plugins kosten Geld, andere sind vollständig umsonst oder bieten einen kostenfreien Grundumfang an. Auch das CMS selbst ist für nicht-kommerzielle Nutzung sehr oft umsonst zu haben.

Die vorliegende Website beruht auf dem CMS „WordPress“ und benutzt einige kostenfreie Plugins.

Server-Hardware, Rechenzentrum

Server werden meist mit dem Betriebssystem Unix (überwiegend „Debian“) ausgestattet. Sie stehen in physisch gut gesicherten Rechenzentren, haben redundante Stromversorgung, Kühlung und eine schnelle Internetanbindung (Upload-Geschwindigkeit). Es gibt dedizierte Server, also wirklich separate Hardware, die man bei einem entsprechenden Anbieter mieten kann. Oft ist man aber auch mit einem virtuellen Server zufrieden. Das ist aus logischer Sicht ein separater Rechner, der aber physikalisch (CPU, Memory,Disk, Netzwerk) Resourcen mit anderen virtullen Rechnern teilt.

Die vorliegende Website läuft auf einem virtuellen Server des Providers ip-projects.de.

Als Mieter eines virtuellen Servers hat man technisch alle Rechte („root“-Zugang).

Wenn man einfach nur eine WordPress-Seite ins Web stellen möchte, dann gibt es noch deutlich preiswertere Angebote, bei denen man innerhalb eines virtuellen Servers, den der Provider betreibt, eine CMS-INstanz eingerichtet bekommt.
Man meldet sich dann als Administrator bei WordPress auf diesem Rechner an und kann die eigene Website bearbeiten.

Damit das funktioniert, muss man gleichzeitig mindestens eine Domain erwerben, die der Provider dann mit dieser WordPress-Instanz verknüpft.

Domains

Man entscheidet sich für eine TLD (Top Level Domain, also z.B. .de, .org, .com, .net) und prüft dann im Web bei entsprechenden Domain-Suchmaschinen, ob die gewünschte Domain frei ist. Dann teilt man diese Domain dem Server-Provider mit, er besorgt sie und man bezahlt 5..10 € Jahresmiete dafür. Damit man die Domain unter https (also „secure“) erreichen kann, muss noch ein Zertifikat ausgestellt werden, Dies übernimmt auch der Provider.

Wenn alles richtig eingerichtet ist, landet eine Anfrage nach fitzliputzli.de dann irgendwann genau auf dem virtuellen Server und in der WordPress-Installation, die man gemietet hat.

Praktische Übungen zum besseren Veständnis

Lokale Datei

  1. Erstelle eine Datei namens „index.html“ an einem beliebigen Ort im Dateisystem deines Rechners.
  2. Benutze eine Texteditor dazu, wie z.B. Programmer´s Notepad.
  3. Schreibe folgenden Text in die Datei „Hällo Wörld!“.
  4. Ziehe die Datei vom Explorer in den Browser und beobachte, was passiert. Schau den Inhalt der URL-Zeile an!
  5. Wird der Text korrekt angezeigt oder sind die „Umlaute kaputt“?

Localhost

  1. Installiere xampp (nur Apache, evtl. mysql)
  2. Prüfe die Installation, indem du „http://localhost“ aufrufst.
  3. Verschiebe die Datei aus der ersten Übung („index.html“) in das Web-Root-Verzeichnis von xampp
  4. Rufe „localhost/index.html“ auf.
  5. Benenne die Datei in „hallo.html“ um und rufe localhost/hallo.html auf.
  6. Benenne die Datei in „hallo.xyz“ um rufe „localhost/hallo.xyz“ auf.

LAN-Kommunikation

  1. Öffne eine cmd-shell und gib „ipconfig“ ein. Notiere deine lokale <IP>.
  2. Rufe vom eigenen Rechner aus <IP>/index.html auf
  3. Rufe genau die selbe Adresse von einem anderen Rechner im LAN aus auf.

WAN-Kommunikation

Achtung: die folgende Übung ist nur etwas für Erfahrene!

  1. Rufe eine Seite im Web auf, die dir deine EXTERNE IP anzeigt. (<EIP>)
  2. Melde dich in deinem Router an und erteile eine Freigabe für deinen lokalen Rechner (Port 80) auf einem exotischen Port (43752 z.B.)
  3. Nimm dein Handy und schalte WLAN aus, so dass die WEbverbindung über die SIM-Karte läuft.
  4. Gib im Handy <EIP>:43752/index.html ein
  5. Lösche die Freigabe im Router wieder.

Blinkender Text

Jetzt ist es an der Zeit, ein paar HTML, CSS und JS Anweisungen auszuprobieren.

  1. Erstelle eine Datei namens blink1.html.
  2. Sie soll in drei verschiedenen Farben, zentriert und in großer Schrift ohne Serifen die folgenden Wörter anzeigen „Schüler-Labor FWSW 2020„.
  3. Benutze CSS, um für Zentrierung, Font, Schriftgröße und Wortabstände zu sorgen.
  4. Die drei Wörter sollen im Sekundentakt der Reihe nach aufleuchten bzw. verschwinden. Realisiere diese Funktionalität mit reinem CSS.
  5. Erstelle einen andere Datei namens „blink2.html“ und realisiere die Blink-Funktion diesmal mit Javascript.
  6. Zeige, dass die Javascript-Realisierung mächtiger ist. Ändere z.B. bei jedem Durchlauf die Farbe jedes Wortes ab (zufälliger Wert, aber nicht zu hell, damit die Schrift lesbar bleibt).