|
Linux is like a wigwam. No Gates no Windows but always an
apache inside
Zitat unbekannter Herkunft
|
Hypertext Transfer Protocol
Ein Webserver ist ein Prozess der Anfragen nach dem Protokoll HTTP beantwortet.
Das Programmpaket apache ist ein Open Source Projekt und gilt als der
meistverwendete WWW-Server im Internet.
HTTP ist die Abkürzung von Hypertext Transfer Protocol und ist in der
RFC 1945 definiert.
Den passenden Client nennt man Browser, die bekanntesten sind
Firefox, Chromium, Safari und der Microsoft Internet Explorer.
Hypertext und HTML
Hypertext und Verweise
Hypertext ist ein Text mit aktiven Verweisstellen auf andere Texte.
Im Web werden sie Links genannt. So ist es möglich, Texte zu schreiben, die
eine Materie auf hohem Niveau behandeln. Anfänger können durch die Verweise
auf die
erforderlichen Erläuterungen und Definitionen geführt werden, während der
Experte seine Informationen komprimiert erhält.
Hypertexte eignet sich auch ideal, um Informationen abzulegen, die
stark miteinander verknüpft ist.
HTML und Tags
Die Sprache HTML (Hypertext Markup Language) ist sehr einfach zu lernen.
Für die Beispiele werden hier einige ausgewählte Grundlagen vorgestellt.
HTML-Dateien können mit einem einfachen Editor erstellt werden und haben
neben dem
eigentlichen Text Darstellungsbefehle, die Tag (engl. Etikett) genannt werden.
Ein Tag ist in spitzen Klammern eingeschlossen. In den meisten Fällen gilt ein
Tag für einen Bereich. Der Geltungsbereich wird durch das Ende-Tag begrenzt,
dass man daran erkennt, dass ein Schrägstrich hinter der geöffneten, spitzen Klammer
steht.
Die Startseite einer Präsenz heißt normalerweise index.html oder
index.htm. Sie hat folgenden Inhalt:
<HTML>
<HEAD>
</HEAD>
<BODY>
<H1>Große Überschrift</H1>
Schauen Sie sich diesen <A HREF="quatsch.html">Quatsch</A> an.
</BODY>
</HTML>
|
HTML, HEAD, BODY, Hx und A
Die Tags HTML und BODY rahmen den Körper einer Webseite ein.
Der Abschnitt HEAD ist für Informationen, die beispielsweise
Suchmaschinen auswerten und auch der Titel der Webseite.
H1 ist eine Überschrift (engl. header). Es gibt noch H2, H3, H4 und H5,
die immer kleiner werdende Überschriften erzeugen.
Das Tag A dient der Adressierung und besitzt Attribute. Mit HREF
(Hyperreferenz) wird auf die angegebene Datei, hier quatsch.html
verwiesen.
Der Text der zwischen <A> und </A> wird bei der Darstellung durch den
Browser unterstrichen und blau dargestellt,
als Zeichen, dass man durch einen Klick hierauf an eine andere Stelle
springt. In diesem Fall führt es zum Laden der Datei quatsch.html
auf dem gleichen Server.
Es wird die Seite quatsch.html, die ja von index.html
angesprungen wird, benötigt. Sie sieht nicht viel
anders aus.
<HTML>
<BODY>
<H1>Großer Quatsch</H1>
<H4>Kleiner Quatsch</H4>
Und hier geht es <A HREF="index.html">zur Hauptseite</A>.
</BODY>
</HTML>
|
Gestaltungselemente
Absatz und Umbruch
Aller Text wird vom Browser hintereinander geschrieben. Um einen Absatz
zu erzeugen, wird das Tag <P> eingefügt. Soll nur einen Zeilenumbruch
ohne Abstand erreicht werden, verwendet man <BR>.
Tabelle
Eine in HTML geschriebene Tabelle sieht auf den ersten Blick etwas kompliziert
aus. Das liegt daran, dass sie gleich drei Tags verwendet. Das erste ist TABLE,
das die gesamte Tabelle umschließt. TR umschließt die Tabellenzeile und TD
eine Spalte innerhalb der Zeile.
Der Browser übernimmt das korrekte Ausrichten.
Man braucht also keine Gedanken darauf verschwenden, welchen Platz eine Spalte
braucht. Das folgende Beispiel erzeugt eine Tabelle, die noch einmal die Tags
beschreibt:
<TABLE BORDER>
<TR><TD> table </TD><TD> Die ganze Tabelle </TD></TR>
<TR><TD> tr </TD><TD> Eine Spalte </TD></TR>
<TR><TD> td </TD><TD> Ein Feld </TD></TR>
</TABLE>
|
Positionierung per Tabelle
Das Attribut BORDER versieht die Tabelle mit einem Rahmen.
Auch ohne Rahmen machen Tabellen Sinn. Man benötigt sie, um Texte
nebeneinander zu positionieren.
Durch das Verschachteln mehrerer Tabellen können auch kompliziertere
Anordnungen realisiert werden.
Formulare
Benutzereingaben
Zur Erstellung von Eingabemasken und Kontrollelementen wird
in HTML ein Formular verwendet. Der Inhalt
des Formulars wird entweder auf dem Server selbst verarbeitet
oder kann per E-Mail versandt werden. Die Verarbeitung der Formularinhalte
wird später noch einmal beim Thema CGI auftauchen.
Formular-Rahmen
Jedes Formular wird unsichtbar durch das Tag FORM eingerahmt. Im Starttag
wird Aktion und Versendungsmethode festgelegt.
<FORM ACTION="mailto:informatik-ecke@willemer.de" METHOD=post>
...
</FORM>
|
Dies ist ein typisches Beispiel für das Versenden des
Formularinhaltes per E-Mail.
Der Browser wird versuchen, den Formularinhalt an die genannte
E-Mail Adresse zu senden.
<FORM ACTION="/cgi-bin/tuwas" METHOD=get>
...
</FORM>
|
Der Inhalt dieses Formulars wird von dem Programm tuwas
verarbeitet. Dieses muss sich auf dem Server in dem für CGIs definierten
Verzeichnis befinden.
Die Bedeutung der Attribute sind:
- action=
- Hier wird der Name des Programmes auf
dem Server angegeben, das das Formularergebnis bearbeitet. Ausnahme
ist die Anweisung mailto, die den Inhalt an eine
Adresse versenden lässt. In diesem Fall sollte die Methode
POST verwendet werden.
- method=get
- Die Daten werden in der Environmentvariable
QUERY_STRING abgelegt. Das CGI-Programm liest diese Variable aus.
- method=post
- Die Daten werden per Standardeingabe an das CGI Programm
geliefert.
Die Environmentvariable CONTENT_LENGTH enthält die Länge
der Eingabe.
Eingabe- und Kontrollelemente
Ein Formular wird erst durch die Bestückung mit
Kontrollelementen lebendig. Ein Kontrollelement wird mit dem Tag INPUT
gekennzeichnet. Mit dem Attribut TYPE wird der Typ gekennzeichnet werden.
An dieser Stelle sollen nur zwei Elementetypen
betrachtet werden. Das eine ist das SUBMIT. Es ist der Bestätigungsknopf,
der in jedem Fomular dafür sorgt, dass die Eingaben abgeschickt werden.
Das andere ist TEXT, das die Eingabe von Text ermöglicht.
Mit dem Attribut VALUE kann die Vorbelegung des Eingabeelements erfolgen.
Ganz wichtig ist das Attribut NAME, an dem man bei der Auswertung die
einzelnen Kontrollelemente erkennen kann. Also müssen die Namen für das
jeweilige Formular eindeutig sein.
SUBMIT
Jedes Formular enthält normalerweise einen Button zum Absenden
des Formularinhalts an das CGI-Programm oder die E-Mail. Dieser
Button ist vom Typ SUBMIT. Erst wenn der Betrachter
diesen Knopf betätigt, wird die ACTION des Formulars aktiv.
<form>
<input type=submit value="OK">
</form>
|
Texteingabefeld TEXT
Mit dem Kontrollelementtyp TEXT können Textzeilen eingegeben werden.
Beispiel:
<FORM>
Welches Auto fahren Sie?
<INPUT TYPE=TEXT NAME="auto" VALUE="Alt aber bezahlt"
SIZE=20 MAXLENGTH=60>
<TEXTAREA Name="Adresse" ROWS=5 COLS=60>
Ihre Adresse
</TEXTAREA>
</FORM>
|
TEXTAREA
Eine Abart des TEXT ist die TEXTAREA, die mehrere Zeilen Text aufnehmen kann.
Man könnte auch von einem simplen Editor reden. Er wird mit dem
Tag TEXTAREA eingeleitet. Der folgende Text bis zum Endetag ist die
Vorbelegung des Kontrollelements, ähnlich wie bei VALUE=.
RADIO
Ein zusammengesetztes Element ist der Radiobutton. Es werden mehrere >>Knöpfe<<
unter gleichem Namen definiert. Nur einer von ihnen kann angewählt werden.
Die folgende Definition bildet realistisch die möglichen Eigenarten von
Menschen ab.
<INPUT TYPE="RADIO" NAME="eigenschaft" VALUE="intelligent">
<INPUT TYPE="RADIO" NAME="eigenschaft" VALUE="sportlich">
<INPUT TYPE="RADIO" NAME="eigenschaft" VALUE="schön">
|
Wer nähere und aktuelle Informationen zum Thema HTML braucht, sollte sich
mit
SelfHTML beschäftigen.
Es findet sich bei vielen Linuxdistributionen anbei oder im Internet unter der
URL
http:/de.selfhtml.org
Start des Servers
Das Startskript für den Apachen findet man im Verzeichnis /etc/init.d
unter dem Namen apache2. Für den Start wird es mit dem Argument
start aufgerufen. Um den Server zu stoppen, muss das Argument
stop heißen. Das Argument restart stoppt und startet den Apachen
neu. Und mit dem Argument reload fordert man ihn auf, seine
Konfiguration neu zu lesen, ohne deshalb den Betrieb zu unterbrechen.
# /etc/init.d/apache2 start
Erster Test
Sobald der Server gestartet ist, können erste Seiten mit einem Browser
abgerufen werden. Dazu starten Sie einen Browser und geben in die Adresszeile
http://localhost ein.
Sie können den Server auch von einem anderen Computer im gleichen Netzwerk
ansprechen, indem Sie hinter
http:// den Rechnernamen des Servers oder
dessen IP-Nummer setzen.
Die Datei index.html im Verzeichnis /var/www/html
enthält den HTML-Code, der im Browser zu sehen ist. Sie können ihn anpassen,
um ihren eigenen Inhalt zu publizieren.
Die Konfigurationsdateien
In alten Versionen des Apachen gab es eine einzige Konfigurationsdatei namens
httpd.conf. Diese Datei wurde langsam unübersichtlich und wurde darum
in die Kategorien sites, mod und conf unterteilt.
Da es immer wieder vorkommt, dass Konfigurationen kurzzeitig vom Netz genommen
werden müssen, um später wieder aktiviert zu werden, unterscheidet man zwischen
verfügbaren (available) und aktiven (enabled) Konfigurationen.
Alle Konfigurationsdateien müssen seit Apache 2.4 die Endung
.conf
tragen.
Die Konfiguration einer Website
Im Verzeichnis
/etc/apache2/sites-enabled finden Sie direkt nach der
Installation eine Datei namens
000-default.conf. Diese hat folgenden
Inhalt:
<VirtualHost *:80>
#ServerName www.example.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
In Ihrer Datei werden Sie noch einige Zeilen finden, die mit einem # als
Kommentare gekennzeichnet sind und darum vom Webserver nicht gelesen werden.
Die Konfiguration wird durch einen Tag VirtualHost eingeklammert.
Sie können mehrere solcher virtueller Hosts anlegen.
Der Stern bedeutet an dieser Stelle, dass sich die Konfiguration auf jeden
beliebigen Host bezieht, der - wie hinter dem Doppelpunkt steht - über den
Port 80 angesprochen wird.
Die Direktiven haben folgende Bedeutungen.
- ServerName
- Hier ist der Name, der nicht zwingend dem Hostname des
Rechners entsprechen muss. Hier könnte also auch www.willemer.edu stehen.
Allerdings muss der Name durch /etc/hosts oder DNS bekannt sein.
- ServerAdmin
- Das ist die E-Mailadresse, an die Probleme
weitergeleitet werden.
- DocumentRoot
- Hier stehen die eigentlichen HTML-Dateien. Von außen
gesehen ist dies das WWW Rootverzeichnis des Servers.
- ErrorLog
- Das Verzeichnis, in dem sich die Fehlermeldungen
befinden.
- CustomLog
- Das Verzeichnis, in dem die Zugriffsprotokolle
abgelegt werden.
Indexdateien des Verzeichnisses
Die hinter
DirectoryIndex stehenden Dateinamen werden automatisch
geladen, wenn nur der Verzeichnisname angegeben wird. Dabei werden sie
der Reihe nach durchgegangen, bis apache eine Datei diesen Namens findet.
DirectoryIndex index.html index.htm
|
Directory-Einstellungen
Es können Direktiven auf Verzeichnisse angewandt werden. Damit können
Rechte für verschiedene Verzeichnisse unterschiedlich geregelt
sein. So ist der Zugriff auf das Dokumentverzeichnis normalerweise offener
als der auf die CGI-Skripte.
Die Abschnitte werden wie durch Tags eingeklammert, wobei hinter dem
Einleitungstag der Name des Verzeichnisses steht.
Zunächst wird das Wurzelverzeichnis des Rechners eingestellt. Die Directory
Einträge gelten für alle Unterverzeichnisse, also wirkt dies auf die gesamte
Maschine.
<Directory />
Options -FollowSymLinks +Multiviews
AllowOverride None
</Directory>
|
Damit werden die Zugriffe soweit wie möglich eingeschränkt. In den folgenden
Abschnitten können dann die Zugriffe für spezielle Bereiche gelockert werden.
Interessanter für den Betrieb des Servers sind die Einstellungen des
Verzeichnisses, das oben als DocumentRoot eingetragen wurde:
<Directory "/usr/local/httpd/htdocs">
Options Indexes -FollowSymLinks +Includes MultiViews
AllowOverride All
Order allow,deny
Allow from .willemer.edu
</Directory>
|
Symbolische Links
Die Option
FollowSymLinks ist normalerweise aus Sicherheitsgründen
abgeschaltet. Bei eingeschalteter Option können Dateien und Verzeichnisse
auch als symbolische Links angelegt werden. Das ist besonders praktisch,
wenn man Webseiten erstellt und sie zu Testzwecken in den Serverpfad einbinden
will.
Zugriffsrecht
Die Klausel
Allow legt fest, wer Zugriff auf den Server hat.
Hier steht normalerweise
from all.
Das bedeutet, dass jeder den Server in Anspruch nehmen darf. In diesem
Beispiel ist die Genehmigung auf Rechner eingeschränkt, die der Domäne
willemer.edu angehören. Diese Einstellung ist typisch für einen Intranetserver.
So können Firmeninterna eingestellt werden, die nicht für die breite
Öffentlichkeit gedacht sind. Hinter dem
from können stehen:
| Angabe | Bedeutung |
|---|
| all | jeder beliebige Rechner hat Zugriff |
| .domain.de | Alle Rechner der Domäne domain.de |
| 192.168.109.144 | Nur ein spezieller Rechner |
| 192.168. | Alle Rechner, deren IP mit 192.168.109 beginnen |
Parallel gibt es noch eine Direktive Deny from, die genau das
Gegenteil bewirkt, nämlich das Ausschließen von Rechnern oder Netzen.
Privatadministration per .htaccess
Einige der Konfigurationen, die normalerweise zentral
gemacht werden, kann man auf der Verzeichnisebene in
einer eigenen Datei überschreiben. Allerdings muss das in der zentralen
Konfiguration erlaubt sein. Normalerweise wird dort zumindest soviel
Freiheit gelassen, dass die Systemsicherheit nicht gefährtet ist.
Interessant ist diese Möglichkeit für Kunden von Internetprovidern.
Denn die Wahrscheinlichkeit ist hoch, dass dort
der Apache im Einsatz ist und diese Rechte offen stehen.
Damit stehen auch dem normalen Kunden Administrationsmöglichkeiten offen.
Voraussetzungen in den zentralen Konfigurationsdateien
Mit der Direktive
AccessFileName wird in der Datei
/etc/apache2/apache2.conf der Name der Datei festgelegt, die
die Konfiguration auf Verzeichnisebene steuert.
Normalerweise bleibt es bei dem Standard
.htaccess.
Mit dieser Datei können Direktiven, die normalerweise in der Sektion
Directory stehen, in die Datei
.htaccess des jeweiligen
Verzeichnisses ausgelagert werden.
Allerdings ist die Voraussetzung, dass die Direktive AllowOverride
für das Verzeichnis mindestens FileInfo hat.
Sollen Zugriffskonfigurationen geändert werden, muss
auch das Stichwort AuthConfig genannt sein.
Diese findet sich in der Datei mods-available/userdir.conf.
Die Datei .htaccess kann in allen Unterverzeichnissen des
Verzeichnisbaums
stehen. Unter anderem kann mit der Direktive ErrorDocument
festgelegt werden, dass bestimmte Fehler auf ein Dokument umgeleitet wird.
Fehlende Dateien
Besonders interessant ist
dabei der Fehler File Not Found (404). Es kann eine HTML-Datei angegeben
werden, die in solchen Fehlerfällen angesprungen wird. Auf diese Weise kann
man zwar den Fehler nicht verhindern, aber man kann den Besucher vielleicht
auf den korrekten Index setzen, damit er sich wieder zurecht findet.
# .htaccess
ErrorDocument 404 /err404.html
|
Passwortschutz
Ebenfalls mit einer .htaccess-Datei kann erreicht werden, dass
Benutzer bestimmte Unterverzeichnisse nur nach Nennung von Benutzerkennung
und Passwort zugreifen können. Zunächst ist Voraussetzung, dass in der
httpd.conf die Direktive
AllowOverride mindestens den
Eintrag
AuthConfig aufweist. Dann kann in der .htaccess
mit mehreren Einträgen die Kennworteingabe vorbereitet werden.
AuthType Basic
AuthName "Meine kleine Sicherung"
AuthUserFile htdocs/arnold/.htpasswd
<Limit GET POST>
require valid-users
</Limit>
|
- AuthType
- Hier kann Basic oder Digest stehen. Basic verwendet eine
unsichere Kodierung des Passwortes, allerdings wird Digest nicht von
allen Browsern beherrscht.
- AuthName
- Das ist der Titel der Authorisierung. Er erscheint in der
Dialogbox und dient nur der Information des Anwenders, wofür er hier sein
Passwort hinterlassen soll.
- AuthUserFile
- beschreibt den Pfadnamen der Passwortdatei (siehe unten).
- require valid-users
- bedeutet, dass nur Anwender zugelassen werden, die
in der Passwortdatei unter AuthUserFile aufgeführt sind.
.htpasswd
Die Datei .htpasswd enthält die berechtigten Benutzer. Von einem Doppelpunkt
getrennt erscheint dann das kodierte Passwort. Der Name und der Pfad dieser
Datei wird durch die Direktive AuthUserFile festgelegt. Als Dateiname verwendet
man tradionsgemäß .htpasswd. Der Pfad ist bei einem führenden
Schrägstrich der absolute Pfad auf der Maschine. Bei Verwendung eines
relativen Pfades geht dieser von dem Pfad aus, der in der zentralen Direktive
ServerRoot genannt ist. Will man einen solchen Schutz in der eigenen
Webpräsenz bei einem normalen Provider einbauen, muss man natürlich den
Pfad der eigenen Webseite kennen. Freundliche Provider geben diese Information
in der FAQ oder auf
Anfrage heraus. Wenn Sie freien Zugriff auf den Rechner haben, sollten Sie
die .htpasswd an einen Pfad legen, der außerhalb des ServerRoot
legen, um ein Ausspähen der Passwörter zu erschweren.
Erstellen der .htpasswd
Um die Datei .htpasswd zu erstellen, verwendet man am einfachsten das
Programm
htpasswd. Hier wird eine Datei für die Benutzer arnold und
andrea erstellt.
gaston> htpasswd -bc .htpasswd arnold aBc
Adding password for user arnold
gaston> htpasswd -b .htpasswd andrea PaSw
Adding password for user andrea
gaston> cat .htpasswd
arnold:Htg5PxchrVjLo
andrea:nF9VERTm.Su/Y
gaston>
|
Die Option -c in der ersten Zeile bedeutet create und erzeugt eine
neue Passwortdatei. Weitere Benutzer werden nur mit der Option -b
angehängt. Der Befehl cat zeigt, wie die Datei anschließend von innen
aussieht.
Austausch per HTTP
Wie das Zusammenspiel zwischen Browser und Server abläuft, ist in der RFC 1945
festgelegt.
Ein Webserver tauscht mit dem Browser an sich nur Texte aus.
Durch die Möglichkeiten des Browsers bezüglich Hypertext, also des Verlinkens
von Informationen und der Einbeziehung von Grafiken und anderer Multimedia
wird allerdings eine große Vielfalt erzeugt.
GET, POST und HEAD
Das Protokoll arbeitet mit erstaunlich wenigen Kommandos. Trotzdem mehr
Kommandos definiert sind, werden normalerweise hauptsächlich die Befehle GET,
POST und HEAD eingesetzt.
1)
Beim HTTP ist Groß- und Kleinschreibung relevant.
GET holt eine spezifizierte Datei und entspricht den normalen Anforderungen,
wenn man durch das Web surft. HEAD liest nur den Kopf einer Seite. Dies wird
vor allem von Suchmaschinenrobotern verwendet. Der Befehl POST wird für die
Übertragung von Daten vom Browser an den Server benötigt, typischerweise in
Formularen.
Im folgenden Auszug wird ein GET mit Hilfe des Befehls telnet
simuliert. Zunächst gibt der Client den Befehl GET. Es folgt als Argument
die gewünschte Datei mit dem vom Server aus gesehenen vollständigen Pfad.
Als dritter Parameter folgt die HTTP-Version. Die Zeilen schließen mit
Carriage Return und Line Feed, die durch ctrl-M und ctrl-J bei der Eingabe
erreicht werden.
gaston> telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /index.htm HTTP/1.0
HTTP/1.1 200 OK
Date: Mon, 01 Apr 2002 11:03:01 GMT
Server: Apache/1.3.20 (Linux/SuSE) PHP/4.0.6
Last-Modified: Mon, 01 Apr 2002 11:02:40 GMT
ETag: "4b286-7a-3ca83e50"
Accept-Ranges: bytes
Content-Length: 122
Connection: close
Content-Type: text/html
<HTML>
<BODY>
<H1>Große Überschrift</H1>
Schauen Sie sich diesen <A HREF="quatsch.html">Quatsch</A> an.
</BODY>
</HTML>
Connection closed by foreign host.
gaston>
|
Serverantworten
Der Server antwortet mit seiner HTTP-Version, der Bestätigung für die
Anfrage, diverser Informationen wie Datenumfang und Dateityp. Dann durch
eine Leerzeile getrennt mit dem Inhalt der Datei.
Statusloser Server
Man sieht das Trennen der Verbindung nach dem Übertragen der Seite.
Der apache ist also ein statusloser Server. Das bedeutet, dass er im Gegensatz
zum Newsserver oder Mailserver die Verbindung nach jeder Anfrage abbaut.
Das ist zwar etwas einfacher zu implementieren und bringt auch bessere
Stabilität und Performance, hat aber darin seinen Nachteil, dass jede
Seitenanforderung für den Server neu ist.
In Zeiten der Kommerzialisierung ist es beispielsweise nicht egal, welche
Seiten in welcher Reihenfolge aufgerufen werden. Man möchte natürlich gern,
dass die Maske mit der Kundenadresse auch seinem Warenkorb zugeordnet wird.
Eine solche Wiedererkennung erfolgt über so genannte Cookies oder aber durch
die Identifizierung der Browseraustattung und IP-Nummer des Kundenrechners.
Serverantworten
Der Server antwortet auf Anfragen mit einer Fehlermeldung, die durch eine
dreistellige Zahl eingeleitet wird. Hier sind die in RFC 1945 definierten
Fehlermeldungen in einer Tabellenübersicht dargestellt.
| Basis | Zahlencode | Bedeutung |
|---|
| 1xx | | Informativ |
| 2xx | | Erfolgreich |
| | 200 | OK |
| | 201 | Created |
| | 202 | Accepted |
| | 204 | No Content. Anfrage ok, aber kein neuer Inhalt |
| 3xx | | Es sind weitere Aktionen erforderlich |
| | 300 | Mehrere Auswahlmöglichkeiten |
| | 301 | Permanent auf anderer URL |
| | 302 | Temporär auf anderer URL |
| | 304 | Inhalt ist unverändert |
| 4xx | | Fehler des Client |
| | 400 | Fehlerhafte Anfrage, etwa ungültige URL |
| | 401 | Nicht authorisiert |
| | 403 | Verboten |
| | 404 | Nicht gefunden |
| 5xx | | Fehler des Servers |
| | 500 | Interner Serverfehler |
| | 501 | Nicht implementiert |
| | 502 | Falsches Gateway (Proxy-Anwendung) |
| | 503 | Server ist überlastet |
Wie oben schon
einmal angedeutet, kann man beim Auftreten der Fehlermeldungen auf eine
eigene Seite verweisen, die nähere Informationen zu dem Problem gibt.
Dazu verwendet man die Direktive ErrorDocument. Darauf folgt
zuerst die Fehlernummer, dann das Dokument, das im Falle dieses
Fehlers gerufen werden soll.
ErrorDocument 404 /err404.html
|
Am interessantesten dürfte das für die Fehlermeldung 404 Not Found sein.
Beim Umgestalten von Websites werden durch Zusammenfassungen oft Seiten
entfernt, die durchaus noch in den Suchmaschinen vorhanden sind. Mit einer
eigenen Fehlerdatei kann man einen Link auf die Seiten setzen, die
vergleichbare Informationen haben.
Durch die Möglichkeit eine .htaccess in die Verzeichnisse zu
legen, kann der Benutzer recht dicht an die Seiten geführt werden, die er
nicht gefunden hat.
Virtuelles Hosting
Mit dem virtuellen Hosting ist es möglich, mehrere Web-Domänen auf einem
Rechner zu realisieren. Zunächst müssen beide Domänen, beispielsweise per DNS
auf denselben Rechner zeigen.
Im zweiten Schritt wird in der Konfigurationsdatei httpd.conf
abgestellt, welche Domänen vom Webserver-Prozess bedient werden.
Dazu gibt es die Abschnitte VirtualHost. Beispiel:
<VirtualHost www.willemer.edu>
ServerName www.willemer.edu
ServerAlias willemer.edu *.willemer.edu
DocumentRoot /www/docs/willemer_edu
</VirtualHost>
<VirtualHost www.willi.edu>
ServerName www.willi.edu
ServerAlias willi.edu *.willi.edu
DocumentRoot /www/docs/willi_edu
</VirtualHost>
|
Mehrere Domänen, ein Host
Dieser Server wird also die Anfragen an www.willemer.edu als auch die an
www.willi.edu beantworten. Dieses Verfahren wird bei Domainhostern
eingesetzt, da diese nicht für jede Kundendomäne einen eigenen Rechner
verwenden.
Während wir bisher normalerweise die Situation hatten, dass mehrere Rechner
zu einer Domäne gehören, teilen sich mehrere Domänen hier eine IP-Nummer.
Allerdings ist zu bedenken, dass für Anwendungen mit IP-bassierenden
Zertifikaten wie SSL, es immer noch notwendig ist, eigene IP-Nummern
für jeden Hostnamen zu verwenden.
CGI: der Server schlägt zurück
Schnittstelle für Datenaustausch
CGI ist eine Schnittstelle zwischen dem Webserver und einer Anwendung. Die
Idee ist, dass der Server dem Browser Daten liefert, die nicht starr sind,
sondern durch den Inhalt von Datenbanken oder anderen Applikationen gespeist
sind. Man könnte es so ausdrücken, dass ein normaler Browser zum Frontend
einer Applikation wird. Dazu ist es notwendig, dass Webserver und Applikation
miteinander sprechen. Das Interface hierzu ist CGI.
Bevor aber das erste CGI-Skript starten kann, muss seit Apache Version 2.4
der Einsatz von CGI freigeschaltet werden. Dazu wird das Modul cgi aktiviert.
a2enmod cgi
Serverprogramme starten
Wenn der Browser dynamisch erstellte Daten liefern soll, müssen auf dem
Server Programme oder Skripten ablaufen. Der Serverprozess muss also auf
einen Hinweis im HTML-Quelltext hin diesen Prozess starten. Das Ergebnis des
gestarteten Prozesses soll normalerweise wieder auf dem Browser erscheinen.
Die einfachste Art, von HTML aus einen Prozess auf dem Server zu starten,
geht über einen HREF-Link.
<a href="http://www.server.de/cgi-bin/startmich">Start!</a>
|
Das Verzeichnis cgi-bin liegt typischerweise an anderer Stelle, als die
HTML-Dateien für die Webpräsenz. Der Ort des cgi-bin wird durch die
Konfiguration des Webservers festgelegt.
In der Datei httpd.conf findet sich dazu die Zeile:
ScriptAlias /cgi-bin/ "/usr/local/httpd/cgi-bin/"
|
Betrachten wir nun den angestossenen Skript, der aus Demonstrationszwecken in
einfachster Shell-Sprache der Bourne-Shell gehalten ist.
#!/bin/sh
echo "Content-type: text/html"
echo
# Inititalisierung beendet: es folgt der gesendete Text
echo "<HTML><BODY>
echo "Es ist gut, Sie hier zu sehen.<br>"
echo "MfG, Arnold Willemer"
echo "</BODY></HTML>
|
CGI-Programme geben HTML aus
Die Standardausgabe dieses gestarteten Programmes wird vom Server an den
Browser als Input zugesandt. Wichtig ist die erste Zeile, die den Typ angibt
und die darauf folgende Leerzeile, sonst zeigt der Browser gar nichts an.
Danach wird der normale HTML-Code ausgegeben.
Als CGI-Sprache eignet sich jede Programmiersprache, die den Standard Input
lesen und den Standard Output schreiben kann, also fast jede Sprache.
Perl hat seinen besonderen Platz als CGI-Sprache, weil sie mächtige Befehle
zur Verarbeitung von Texten besitzt und diese in diesem Bereich besonders
hilfreich sind.
Daten an den Server senden
Um das Beispiel zu erweitern, soll die Webseite Daten an den Server senden.
Daten gelangen normalerweise über Formulare an den Webserver, die der Anwender in seinem Browser ausfüllt.
Das folgende Formular wird nach Drücken auf den Button >>Start<< das
Programm /cgi-bin/test02 durchstarten.
<HTML> <HEAD>
<TITLE>Testseite</TITLE>
</HEAD> <BODY>
<FORM ACTION="/cgi-bin/test02" METHOD="POST">
<INPUT TYPE="SUBMIT" VALUE="Start">
</FORM>
</BODY> </HTML>
|
In der Formulardeklaration verbirgt sich der Aufruf des CGI-Programmes unter
ACTION.
Die Übermittlung der Daten aus der Formularmaske an den Skript erfolgt per Standardeingabe, wenn als Methode so wie oben POST verwendet wird. Wenn wir folgende einfache Maske verwenden:
<FORM ACTION="/cgi-bin/test03" METHOD="POST">
<INPUT NAME="Name" VALUE="Name" SIZE=30>
<TEXTAREA Name="Adresse" ROWS=5 COLS=60>
Ihre Adresse
</TEXTAREA>
<INPUT TYPE="RADIO" NAME="Anrede" VALUE="Herr">
<INPUT TYPE="RADIO" NAME="Anrede" VALUE="Frau">
<INPUT TYPE="SUBMIT" VALUE="Start">
</FORM>
|
Die Maske wäre optisch natürlich noch durch eine Tabelle zu strukturieren und erläuternde Texte aufzupeppen. Hier soll es aber nur um den Mechanismus gehen und da kann es gar nicht schlicht genug sein.
Den empfangenden Skript haben wir durch das Lesen der Standardeingabe erweitert.
#!/bin/sh
echo "Content-type: text/html"
echo
# Inititalisierung beendet: es folgt der gesendete Text
read maske
echo $maske
|
Der Inhalt des Formulars wird also in die Environment-Variable maske
gelesen und anschließend wiedergegeben. Wir finden dann auf dem Browser die
Zeile so wiedergegeben, wie das CGI-Programm sie empfängt.
Name=Willemer&Adresse=Ihre+Adresse%0D%0AOrt&Anrede=Frau
|
Format des Formularinhaltes
Man kann anhand der Zeile leicht erkennen, wie der Aufbau der übermittelten
Daten aussieht. Die Zuordnung der Elemente hat die Struktur
Feldname=Wert&Feldname=Wert&Feldname=Wert
|
Die Eingabeelemente werden durch & getrennt. Leerzeichen in Eingabefeldern
werden durch ein + ersetzt. Bei den mehrzeiligen Texteingabefeldern (TEXTAREA)
werden die Zeilen durch %0D%0A abgeschlossen.
Perspektive
Aus den Rohdaten der Formularmaske lassen sich die eingegebenen Werte
isolieren. Damit kann man beispielsweise eine Datenbankanfrage starten.
Das Ergebnis kann man mit HTML-Tags mischen und über die Standardausgabe
an den Browser zurückgeben.
Während beim CGI das Programm die Seite als Ausgabe komplett erzeugt,
werden bei der Programmiersprache PHP
die Befehle in die Webseite eingebunden wird und nur die
zusätzlich errechneten Ausgaben erzeugt, wo der Code steht.
Naheliegenderweise
sind diese Programme etwas schlanker, da nicht auch alle statischen
Seitenbestandteile einzeln programmiert werden müssen.
Der Interpreter von PHP wird nicht als separates Programm gestartet, sondern
als Modul.
Auch Java bedient sich des HTTP-Protokolls. Dort findet es weite Anwendung
für die Kommunikation zum Application-Server.
Mit den Java Server Pages lassen sich - ähnlich wie bei PHP - Programmfragmente
in einer HTML-Seite einbetten.
1
Bowen, Rich/Coar, Ken: Apache und CGI. Markt und Technik, 2000. S. 42.
