2. Grundlagen
In diesem Kapitel stellen wir die Grundlagen der Webprogrammierung vor. Sein Hauptziel ist es, die wichtigsten Prinzipien der Webprogrammierung näherzubringen, die unabhängig von der jeweils zur Umsetzung verwendeten Technologie sind. Es enthält zahlreiche Beispiele, die Sie am besten selbst ausprobieren sollten, um sich nach und nach mit der Philosophie der Webentwicklung vertraut zu machen. Die für die Tests erforderlichen kostenlosen Tools werden am Ende des Dokuments im Anhang mit dem Titel „Web-Tools“ vorgestellt.
2.1. Die Komponenten einer Webanwendung
Machine Serveur
15Client-Rechner
Nummer | Rolle | Gängige Beispiele |
OS Server | Linux, Windows | |
Webserver | Apache (Linux, Windows) IIS (NT), PWS (Win9x), Cassini (Windows + .NET-Plattform) | |
Serverseitig ausgeführte Skripte. Diese können von Servermodulen oder von Programmen außerhalb des Servers ausgeführt werden (CGI). | PERL (Apache, IIS, PWS) VBSCRIPT (IIS, PWS) JAVASCRIPT (IIS, PWS) PHP (Apache, IIS, PWS) JAVA (Apache, IIS, PWS) C#, VB.NET (IIS) | |
Datenbank – Diese kann sich auf demselben Rechner wie das Programm befinden, das sie nutzt, oder über das Internet auf einem anderen Rechner. | Oracle (Linux, Windows) MySQL (Linux, Windows) Postgres (Linux, Windows) Access (Windows) SQL Server (Windows) | |
OS Client | Linux, Windows | |
Webbrowser | Netscape, Internet Explorer, Mozilla, Opera | |
Clientseitige Skripte, die im Browser ausgeführt werden. Diese Skripte haben keinen Zugriff auf die Festplatten des Client-Rechners. | VBscript (IE) JavaScript (IE, Netscape) PerlScript (IE) Applets JAVA |
2.2. Datenaustausch in einer Webanwendung mit Formular
Client-RechnerServer-Rechner
Nummer | Rolle |
Der Browser fordert zum ersten Mal eine URL für (http://machine/url) an. Es werden keine Parameter übergeben. | |
Der Webserver sendet ihm die Webseite dieses URL. Diese kann statisch sein oder dynamisch durch ein Serverskript (SA) generiert werden, das möglicherweise Inhalte aus Datenbanken (SB, SC) verwendet hat. In diesem Fall erkennt das Skript, dass die Seite URL ohne Übergabe von Parametern angefordert wurde, und generiert die Startseite WEB. Der Browser empfängt die Seite und zeigt sie an (CA). Browser-seitige Skripte (CB) konnten die vom Server gesendete Startseite möglicherweise verändern. Anschließend wird die Webseite durch Interaktionen zwischen dem Benutzer (CD) und den Skripten (CB) verändert. Insbesondere werden die Formulare ausgefüllt. | |
Der Benutzer bestätigt die Formulardaten, die daraufhin an den Webserver gesendet werden müssen. Der Browser fordert je nach Fall das ursprüngliche URL oder ein anderes Skript erneut an und übermittelt gleichzeitig die Formularwerte an den Server. Dazu kann er zwei Methoden namens GET und POST verwenden. Nach Erhalt der Anfrage des Clients löst der Server das Skript (SA) aus, das mit dem angeforderten URL verknüpft ist; dieses Skript erkennt die Parameter und verarbeitet sie. | |
Der Server liefert die programmgesteuert erstellte Seite WEB (SA, SB, SC). Dieser Schritt entspricht dem vorherigen Schritt 2. Der Datenaustausch erfolgt nun gemäß den Schritten 2 und 3. |
2.3. Notations
Im Folgenden gehen wir davon aus, dass eine Reihe von Tools installiert wurde, und verwenden die folgenden Bezeichnungen:
Bezeichnung | Bedeutung |
Stammverzeichnis des Apache-Servers | |
Stammverzeichnis der von Apache bereitgestellten Webseiten. Die Webseiten müssen sich in diesem Stammverzeichnis befinden. So entspricht beispielsweise die URL „URL http://localhost/page1.htm“ der Datei <apache-DocumentRoot>\page1.htm. | |
Stammverzeichnis der Verzeichnisstruktur, das mit dem Alias cgi-bin verknüpft ist und in dem CGI-Skripte für Apache abgelegt werden können. So entspricht die URL URL http://localhost/cgi-bin/test1.pl der Datei <apache-cgi-bin>\test1.pl. | |
Stammverzeichnis der von IIS, PWS oder Cassini ausgelieferten Webseiten. Unter diesem Stammverzeichnis müssen sich die Webseiten befinden. So entspricht die Datei URL http://localhost/page1.htm der Datei <IIS-DocumentRoot>\page1.htm. | |
Stammverzeichnis der Perl-Verzeichnisstruktur. Die ausführbare Datei perl.exe befindet sich in der Regel in <perl>\bin. | |
Stammverzeichnis der PHP-Sprachstruktur. Die ausführbare Datei php.exe befindet sich in der Regel in <php>. | |
Stammverzeichnis der Java-Struktur. Die mit Java verbundenen ausführbaren Dateien befinden sich in <java>\bin. | |
Stammverzeichnis des Tomcat-Servers. Beispiele für Servlets finden sich in <tomcat>\webapps\examples\servlets und Beispiele für Seiten in JSP sowie in <tomcat>\webbapps\examples\jsp |
Für jedes dieser Tools wird auf den Anhang verwiesen, der eine Anleitung zur Installation enthält.
2.4. Statische Webseiten, dynamische Webseiten
Eine statische Seite wird durch eine Datei HTML dargestellt. Eine dynamische Seite hingegen wird vom Webserver „on the fly“ generiert. In diesem Abschnitt stellen wir Ihnen verschiedene Tests mit unterschiedlichen Webservern und Programmiersprachen vor, um die Universalität des Webkonzepts zu veranschaulichen. Wir werden zwei Webserver verwenden, nämlich Apache und IIS. IIS ist zwar ein kommerzielles Produkt, wird jedoch in zwei eingeschränkteren, aber kostenlosen Versionen angeboten:
- PWS für Win9x-Rechner
- Cassini für Windows 2000-Rechner und XP
Der Ordner <IIS-DocumentRoot> ist in der Regel der Ordner [lecteur:\inetpub\wwwroot], wobei [lecteur] das Laufwerk (C, D, …) ist, auf dem IIS installiert wurde. Das Gleiche gilt für PWS. Bei Cassini hängt der Ordner <IIS-DocumentRoot> davon ab, wie der Server gestartet wurde. Im Anhang wird gezeigt, dass der Cassini-Server in einem DOS-Fenster (oder über eine Verknüpfung) wie folgt gestartet werden kann:
Die Anwendung [WebServer], auch Cassini-Webserver genannt, akzeptiert drei Parameter:
- /port: Portnummer des Webdienstes. Kann beliebig gewählt werden. Der Standardwert ist 80
- /path: Physischer Pfad zu einem Ordner auf der Festplatte
- /vpath: virtueller Ordner, der dem oben genannten physischen Ordner zugeordnet ist. Beachten Sie, dass die Syntax nicht /path=Pfad lautet, sondern /vpath:Pfad, entgegen der Angabe im obigen Hilfefenster.
Wenn Cassini wie folgt gestartet wird:
dann ist der Ordner P das Stammverzeichnis der Webstruktur des Cassini-Servers. Dieser Ordner wird also durch <IIS-DocumentRoot> bezeichnet. So wie im folgenden Beispiel:
arbeitet der Cassini-Server auf Port 80, und das Stammverzeichnis seiner Verzeichnisstruktur <IIS-DocumentRoot> ist der Ordner [d:\data\devel\webmatrix]. Die zu testenden Webseiten müssen sich unter diesem Stammverzeichnis befinden.
Im weiteren Verlauf wird jede Webanwendung durch eine einzige Datei repräsentiert, die mit einer beliebigen Textdatei erstellt werden kann. Es ist kein IDE erforderlich.
2.4.1. Statische Seite HTML (HyperText Markup Language)
Betrachten wir den folgenden HTML-Code:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
was die folgende Webseite erzeugt:
Die Tests
Test1
- Den Apache-Server starten
- Das Skript essai1.html in <apache-DocumentRoot> einfügen
- die Datei „URL“ unter http://localhost/essai1.html mit einem Browser anzeigen
- Den Apache-Server beenden
Test2
- den Server IIS/PWS/Cassini starten
- Das Skript essai1.html in <IIS-DocumentRoot> einfügen
- die Seite URL http://localhost/essai1.html mit einem Browser anzeigen
2.4.2. Eine Seite ASP (Active Server Pages)
Das Skript essai2.asp:
<html>
<head>
<title>essai 1 : une page asp</title>
</head>
<body>
<center>
<h1>Une page asp générée dynamiquement par le serveur PWS</h1>
<h2>Il est <% =time %></h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
erzeugt die folgende Webseite:
Der Test
- Starten Sie den Server IIS/PWS
- Das Skript essai2.asp in <IIS-DocumentRoot> einfügen
- die Seite URL http://localhost/essai2.asp mit einem Browser aufrufen
2.4.3. Ein Skript PERL (Practical Extracting and Reporting Language)
Das Skript essai3.pl:
#!d:\perl\bin\perl.exe
($secondes,$minutes,$heure)=localtime(time);
print <<HTML
Content-type: text/html
<html>
<head>
<title>essai 1 : un script Perl</title>
</head>
<body>
<center>
<h1>Une page générée dynamiquement par un script Perl</h1>
<h2>Il est $heure:$minutes:$secondes</h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
HTML
;
Die erste Zeile enthält den Pfad zur ausführbaren Datei perl.exe. Dieser muss bei Bedarf angepasst werden. Nach der Ausführung durch einen Webserver erzeugt das Skript die folgende Seite:
Der Test
- Webserver: Apache
- Zur Information: Sehen Sie sich je nach Apache-Version die Konfigurationsdatei srm.conf oder httpd.conf im Verzeichnis <apache>\confs und suchen Sie die Zeile, die sich auf cgi-bin bezieht, um das Verzeichnis <apache-cgi-bin> zu ermitteln, in dem essai3.pl abgelegt werden soll.
- Legen Sie das Skript essai3.pl in <apache-cgi-bin> ab
- Rufen Sie die URL http://localhost/cgi-bin/essai3.pl auf
Beachten Sie, dass das Laden der Seite perl länger dauert als das der Seite asp. Dies liegt daran, dass das Perl-Skript von einem Perl-Interpreter ausgeführt wird, der erst geladen werden muss, bevor das Skript ausgeführt werden kann. Er verbleibt nicht dauerhaft im Arbeitsspeicher.
2.4.4. Ein Skript PHP (HyperText-Prozessor)
Das Skript essai4.php
<html>
<head>
<title>essai 4 : une page php</title>
</head>
<body>
<center>
<h1>Une page PHP générée dynamiquement</h1>
<h2>
<?
$maintenant=time();
echo date("j/m/y, h:i:s",$maintenant);
?>
</h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
Das obige Skript erzeugt die folgende Webseite:
Die Tests
Test1
- Die Apache-Konfigurationsdatei srm.conf oder httpd.conf in <Apache>\confs einsehen
- Zur Information: Überprüfen Sie die Konfigurationszeilen von php
- Starten Sie den Apache-Server
- Fügen Sie essai4.php in <apache-DocumentRoot> ein
- Rufen Sie die Seite URL unter http://localhost/essai4.php auf
Test2
- den Server IIS/PWS starten
- Zur Information: Überprüfen Sie die Konfiguration von PWS in Bezug auf PHP
- essai4.php in <IIS-DocumentRoot>\php einfügen
- den URL unter http://localhost/essai4.php aufrufen
2.4.5. Ein Skript JSP (Java Server Pages)
Das Skript heure.jsp
<% //Java-Programm zur Anzeige der Uhrzeit %>
<%@ page import="java.util.*" %>
<%
// Code JAVA zur Berechnung der Uhrzeit
Calendar calendrier=Calendar.getInstance();
int heures=calendrier.get(Calendar.HOUR_OF_DAY);
int minutes=calendrier.get(Calendar.MINUTE);
int secondes=calendrier.get(Calendar.SECOND);
// Stunden, Minuten und Sekunden sind globale Variablen
//, die im Code HTML verwendet werden können
%>
<% // Code HTML %>
<html>
<head>
<title>Page JSP affichant l'heure</title>
</head>
<body>
<center>
<h1>Une page JSP générée dynamiquement</h1>
<h2>Il est <%=heures%>:<%=minutes%>:<%=secondes%></h2>
<br>
<h3>A chaque fois que vous rechargez la page, l'heure change</h3>
</body>
</html>
Nach der Ausführung durch den Webserver erzeugt dieses Skript die folgende Seite:
Die Tests
- Das Skript heure.jsp in <tomcat>\jakarta-tomcat\webapps\examples\jsp (Tomcat 3.x) oder in <tomcat>\webapps\examples\jsp (Tomcat 4.x) ablegen
- Starten Sie den Tomcat-Server
- die Seite URL unter http://localhost:8080/examples/jsp/heure.jsp aufrufen
2.4.6. Eine Seite ASP.NET
Das Skript heure1.aspx:
<html>
<head>
<title>Démo asp.net </title>
</head>
<body>
Il est <% =Date.Now.ToString("hh:mm:ss") %>
</body>
</html>
Nach der Ausführung durch den Webserver erzeugt dieses Skript die folgende Seite:
Für diesen Test ist ein Windows-Rechner erforderlich, auf dem die Plattform .NET installiert wurde (siehe Anhang).
- Das Skript heure1.aspx in <IIS-DocumentRoot> einfügen
- Starten Sie den Server IIS/CASSINI
- die Seite URL unter http://localhost/heure1.aspx aufrufen
2.4.7. Fazit
Die vorangegangenen Beispiele haben gezeigt, dass:
- eine Seite HTML dynamisch durch ein Programm generiert werden kann. Darin liegt der Sinn der Webprogrammierung.
- dass die verwendeten Sprachen und Webserver vielfältig sein können. Derzeit lassen sich folgende große Trends beobachten:
- die Kombinationen Apache/PHP (Windows, Linux) und IIS/PHP (Windows)
- die ASP.NET-Technologie auf Windows-Plattformen, die den IIS-Server mit einer .NET-Sprache (C#, VB.NET, …) kombiniert
- die Technologie der Java-Servlets und JSP-Seiten, die mit verschiedenen Servern (Tomcat, Apache, IIS) und auf verschiedenen Plattformen (Windows, Linux) laufen.
2.5. Browser-seitige Skripte
Eine HTML-Seite kann Skripte enthalten, die vom Browser ausgeführt werden. Es gibt zahlreiche browserbasierte Skriptsprachen. Hier sind einige davon:
Sprache | Unterstützte Browser |
VBScript | IE |
JavaScript | IE, Netscape |
PerlScript | IE |
Java | IE, Netscape |
Schauen wir uns ein paar Beispiele an.
2.5.1. Eine Webseite mit einem VBScript-Skript auf der Browserseite
Die Seite vbs1.html
<html>
<head>
<title>essai : une page web avec un script vb</title>
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
</head>
<body>
<center>
<h1>Une page Web avec un script VB</h1>
<table>
<tr>
<td>Cliquez sur le bouton</td>
<td><input type="button" value="OK" name="cmdOK" onclick="reagir"></td>
</tr>
</table>
</body>
</html>
Die oben genannte Seite HTML enthält nicht nur den Code HTML, sondern auch ein Programm, das vom Browser ausgeführt werden soll, der diese Seite geladen hat. Der Code lautet wie folgt:
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
Die Tags <script></script> dienen dazu, Skripte auf der Seite HTML abzugrenzen. Diese Skripte können in verschiedenen Sprachen geschrieben sein, und die Option language des Tags <script> gibt die verwendete Sprache an. Hier ist es VBScript. Wir werden nicht näher auf diese Sprache eingehen. Das obige Skript definiert eine Funktion namens réagir, die eine Meldung anzeigt. Wann wird diese Funktion aufgerufen? Das verrät uns die folgende Codezeile HTML:
Das Attribut onclick gibt den Namen der Funktion an, die aufgerufen werden soll, wenn der Benutzer auf die Schaltfläche OK klickt. Sobald der Browser diese Seite geladen hat und der Benutzer auf die Schaltfläche OK klickt, wird folgende Seite angezeigt:
Die Tests
Nur der Browser IE ist in der Lage, Skripte vom Typ VBScript auszuführen. Netscape benötigt hierfür zusätzliche Software-Erweiterungen. Folgende Tests können durchgeführt werden:
- Apache-Server
- Skript vbs1.html in <apache-DocumentRoot>
-
die URL http://localhost/vbs1.html mit dem Browser IE aufrufen
-
Server IIS/PWS
- Skript vbs1.html in <pws-DocumentRoot>
- die URL http://localhost/vbs1.html mit dem Browser IE aufrufen
Eine Webseite mit einem browserbasierten JavaScript-Skript
La page : js1.html
<html>
<head>
<title>essai 4 : une page web avec un script Javascript</title>
<script language="javascript">
function reagir(){
alert ("Vous avez cliqué sur le bouton OK");
}
</script>
</head>
<body>
<center>
<h1>Une page Web avec un script Javascript</h1>
<table>
<tr>
<td>Cliquez sur le bouton</td>
<td><input type="button" value="OK" name="cmdOK" onclick="reagir()"></td>
</tr>
</table>
</body>
</html>
Hier haben wir etwas Ähnliches wie auf der vorherigen Seite, nur dass wir die Sprache VBScript durch JavaScript ersetzt haben. Dieses hat den Vorteil, dass es sowohl vom Browser IE als auch von Netscape unterstützt wird. Die Ausführung liefert dieselben Ergebnisse:
Die Tests
- Apache-Server
- Skript js1.html in <apache-DocumentRoot>
-
die URL http://localhost/js1.html mit dem Browser IE oder Netscape aufrufen
-
Server IIS/PWS
- Skript js1.html in <pws-DocumentRoot>
- die URL http://localhost/js1.html mit dem Browser IE oder Netscape aufrufen
2.6. Der Austausch zwischen Client und Server
Kehren wir zu unserem Ausgangsdiagramm zurück, das die Akteure einer Webanwendung veranschaulichte:
Server
Wir befassen uns hier mit dem Datenaustausch zwischen dem Client-Rechner und dem Server-Rechner. Dieser erfolgt über ein Netzwerk, und es ist sinnvoll, die allgemeine Struktur des Datenaustauschs zwischen zwei entfernten Rechnern noch einmal in Erinnerung zu rufen.
2.6.1. Das Modell OSI
Das von der ISO (International Standards Organisation) definierte Modell für offene Netzwerke mit der Bezeichnung OSI (Open Systems Interconnection Reference Model) beschreibt ein ideales Netzwerk, in dem die Kommunikation zwischen Rechnern durch ein siebenstufiges Modell dargestellt werden kann:
Jede Schicht erhält Dienste von der darunterliegenden Schicht und stellt ihre eigenen Dienste der darüberliegenden Schicht zur Verfügung. Nehmen wir an, zwei Anwendungen auf unterschiedlichen Rechnern A und B möchten miteinander kommunizieren: Dies geschieht auf der Ebene der Schicht Application. Sie müssen nicht alle Details der Funktionsweise des Netzwerks kennen: Jede Anwendung übergibt die Informationen, die sie übertragen möchte, an die darunterliegende Schicht, nämlich die Schicht Présentation. Die Anwendung muss daher nur die Schnittstellenregeln zur Schicht Présentation kennen. Sobald sich die Informationen in der Schicht Présentation befinden, werden sie nach anderen Regeln an die Schicht Session weitergeleitet und so weiter, bis die Informationen auf dem physikalischen Medium ankommen und physikalisch an den Zielrechner übertragen werden. Dort durchläuft sie den umgekehrten Prozess, den sie auf dem Absenderrechner durchlaufen hat.
Auf jeder Schicht sendet der für den Versand der Informationen zuständige Senderprozess diese an einen Empfängerprozess auf dem anderen Rechner, der derselben Schicht angehört wie er selbst. Dies geschieht nach bestimmten Regeln, die als Protokoll der jeweiligen Schicht bezeichnet werden. Daraus ergibt sich folgendes endgültiges Kommunikationsschema:
Die verschiedenen Schichten haben folgende Aufgaben:
Gewährleistet die Übertragung von Bits über ein physikalisches Medium. In dieser Schicht finden sich Endgeräte zur Datenverarbeitung (E.T.T.D.), wie z. B. Terminals oder Computer, sowie Geräte zum Abschluss von Datenverbindungen (E.T.C.D.), wie z. B. Modulatoren/Demodulatoren, Multiplexer und Konzentratoren. Die wichtigsten Aspekte auf dieser Ebene sind: . die Wahl der Informationskodierung (analog oder digital) . die Wahl des Übertragungsmodus (synchron oder asynchron). | |
Versteckt die physikalischen Besonderheiten der physikalischen Schicht. Erkennt und korrigiert Übertragungsfehler. | |
Verwaltet den Weg, den die über das Netzwerk gesendeten Informationen nehmen müssen. Dies wird als routage bezeichnet: die Bestimmung der Route, die eine Information nehmen muss, damit sie ihren Empfänger erreicht. | |
Ermöglicht die Kommunikation zwischen zwei Anwendungen, während die vorherigen Schichten nur die Kommunikation zwischen Rechnern zuließen. Ein von dieser Schicht bereitgestellter Dienst kann das Multiplexing sein: Die Transportschicht kann dieselbe Netzwerkverbindung (von Rechner zu Rechner) nutzen, um Informationen mehrerer Anwendungen zu übertragen. | |
In dieser Schicht finden sich Dienste, die es einer Anwendung ermöglichen, eine Arbeitssitzung auf einem Remote-Rechner zu eröffnen und aufrechtzuerhalten. | |
Sie zielt darauf ab, die Darstellung der Daten auf den verschiedenen Rechnern zu vereinheitlichen. So werden Daten, die von Rechner A stammen, von der Schicht Présentation des Rechners A gemäß einem Standardformat „aufbereitet“, bevor sie über das Netzwerk gesendet werden. Sobald sie die Schicht Présentation des Zielrechners B erreichen, der sie anhand ihres Standardformats erkennt, werden sie auf andere Weise aufbereitet, damit die Anwendung des Rechners B sie erkennen kann. | |
Auf dieser Ebene befinden sich die Anwendungen, die in der Regel nah am Benutzer angesiedelt sind, wie beispielsweise E-Mail oder Dateiübertragung. |
2.6.2. Das Modell TCP/IP
Das Modell OSI ist ein ideales Modell. Die Protokollsuite TCP/IP kommt diesem in folgender Form nahe:
- Die Netzwerkschnittstelle (die Netzwerkkarte des Computers) übernimmt die Funktionen der Schichten 1 und 2 des Modells OSI
- Die Schicht IP (Internet Protocol) übernimmt die Funktionen der Schicht 3 (Netzwerk)
- Die Schicht TCP (Transfer Control Protocol) oder UDP (User Datagram Protocol) übernimmt die Funktionen der Schicht 4 (Transport). Das Protokoll TCP stellt sicher, dass die zwischen den Rechnern ausgetauschten Datenpakete ihr Ziel erreichen. Ist dies nicht der Fall, sendet es die fehlgeleiteten Pakete zurück. Das Protokoll UDP übernimmt diese Aufgabe nicht, sodass es dem Anwendungsentwickler obliegt, dies zu tun. Aus diesem Grund wird im Internet, das kein zu 100 % zuverlässiges Netzwerk ist, vor allem das Protokoll TCP verwendet. Man spricht dann von einem TCP-IP-Netzwerk.
- Die Anwendungsschicht deckt die Funktionen der Schichten 5 bis 7 des OSI-Modells ab.
Webanwendungen befinden sich in der Schicht Application und stützen sich somit auf die Protokolle TCP-IP. Die Schichten Application der Client- und Server-Rechner tauschen Nachrichten aus, die den Schichten 1 bis 4 des Modells zur Weiterleitung an den Bestimmungsort übergeben werden. Um sich zu verstehen, müssen die Anwendungsschichten beider Rechner dieselbe Sprache bzw. dasselbe Protokoll „sprechen“. Das Protokoll für Webanwendungen heißt HTTP (HyperText Transfer Protocol). Es handelt sich um ein textbasiertes Protokoll, c.a.d, bei dem die Rechner Textzeilen über das Netzwerk austauschen, um sich zu verständigen. Dieser Austausch ist standardisiert, sodass dem Client eine bestimmte Anzahl von Nachrichten zur Verfügung steht, um dem Server genau mitzuteilen, was er möchte, und der Server ebenfalls über eine bestimmte Anzahl von Nachrichten verfügt, um dem Client seine Antwort zu übermitteln. Dieser Nachrichtenaustausch hat folgende Form:
Client --> Server
Wenn der Client seine Anfrage an den Webserver sendet, übermittelt er
- Textzeilen im Format HTTP, um anzugeben, was er möchte
- eine Leerzeile
- optional ein Dokument
Server --> Client
Wenn der Server dem Client antwortet, sendet er
- Textzeilen im Format HTTP, um anzugeben, was er sendet
- eine leere Zeile
- optional ein Dokument
Der Datenaustausch hat also in beide Richtungen die gleiche Form. In beiden Fällen kann ein Dokument gesendet werden, auch wenn es selten vorkommt, dass ein Client ein Dokument an den Server sendet. Das Protokoll HTTP sieht dies jedoch vor. Dadurch können beispielsweise Kunden eines Internetanbieters verschiedene Dokumente auf ihre bei diesem Anbieter gehostete persönliche Website hochladen. Die ausgetauschten Dokumente können beliebiger Art sein. Nehmen wir einen Browser, der eine Webseite mit Bildern anfordert:
- Der Browser stellt eine Verbindung zum Webserver her und fordert die gewünschte Seite an. Die angeforderten Ressourcen werden eindeutig durch URL (Uniform Resource Locator) bezeichnet. Der Browser sendet lediglich HTTP-Header und kein Dokument.
- Der Server antwortet ihm. Er sendet zunächst HTTP-Header, die angeben, welche Art von Antwort er sendet. Dies kann ein Fehler sein, wenn die angeforderte Seite nicht existiert. Wenn die Seite existiert, gibt der Server in den HTTP-Header seiner Antwort an, dass er im Anschluss daran ein Dokument im Format HTML (HyperText Markup Language) senden wird. Dieses Dokument besteht aus einer Folge von Textzeilen im Format HTML. Ein HTML-Text enthält Tags (Markierungen), die dem Browser Anweisungen zur Darstellung des Textes geben.
- Der Client weiß anhand der HTTP-Header des Servers, dass er ein HTML-Dokument erhalten wird. Er analysiert dieses Dokument und stellt möglicherweise fest, dass es Bildverweise enthält. Diese sind im Dokument HTML nicht enthalten. Daher sendet er eine neue Anfrage an denselben Webserver, um das erste benötigte Bild anzufordern. Diese Anfrage ist identisch mit der in Schritt 1, nur dass die angeforderte Ressource eine andere ist. Der Server bearbeitet diese Anfrage, indem er dem Client das angeforderte Bild sendet. Diesmal geben die Header des Dokuments HTTP in der Antwort an, dass es sich bei dem gesendeten Dokument um ein Bild und nicht um ein Dokument HTML handelt.
- Der Client empfängt das gesendete Bild. Die Schritte 3 und 4 werden so lange wiederholt, bis der Client (in der Regel ein Browser) über alle Dokumente verfügt, die er zur Anzeige der gesamten Seite benötigt.
2.6.3. Das Protokoll HTTP
Lassen Sie uns das Protokoll HTTP anhand von Beispielen näher betrachten. Was tauschen ein Browser und ein Webserver aus?
2.6.3.1. Die Antwort eines HTTP-Servers
Hier werden wir sehen, wie ein Webserver auf Anfragen seiner Clients reagiert. Der Webdienst oder HTTP-Dienst ist ein TCP-IP-Dienst, der normalerweise auf Port 80 läuft. Er könnte jedoch auch auf einem anderen Port laufen. In diesem Fall müsste der Client-Browser diesen Port in der von ihm angeforderten URL angeben. Eine URL hat im Allgemeinen folgende Form:
mit
Protokoll | http für den Webdienst. Ein Browser kann auch als Client für FTP-, News-, Telnet-Dienste usw. dienen. |
Rechner | Name des Rechners, auf dem der Webdienst läuft |
Port | Port des Webdienstes. Bei Port 80 kann die Portnummer weggelassen werden. Dies ist der häufigste Fall |
Pfad | Pfad, der auf die angeforderte Ressource verweist |
Infos | zusätzliche Informationen, die dem Server übermittelt werden, um die Anfrage des Clients zu präzisieren |
Was macht ein Browser, wenn ein Benutzer das Laden einer URL anfordert?
- Er eröffnet eine TCP-IP-Verbindung mit dem Rechner und dem Port, die im Abschnitt „machine[:port]“ des URL angegeben sind. Eine TCP-IP-Verbindung zu öffnen bedeutet, eine „Kommunikationsverbindung“ zwischen zwei Rechnern herzustellen. Sobald diese Verbindung hergestellt ist, werden alle zwischen den beiden Rechnern ausgetauschten Informationen über sie übertragen. Die Erstellung dieser Verbindung TCP-IP beinhaltet noch nicht das Webprotokoll HTTP.
- Sobald die Verbindung TCP-IP hergestellt ist, sendet der Client seine Anfrage an den Webserver, indem er Textzeilen (Befehle) im Format HTTP an ihn übermittelt. Er sendet dem Server den Teil „Pfad/Informationen“ des URL
- Der Server antwortet auf die gleiche Weise und über dieselbe Verbindung
- Einer der beiden Partner trifft die Entscheidung, die Verbindung zu schließen. Dies hängt vom verwendeten Protokoll HTTP ab. Beim Protokoll HTTP 1.0 schließt der Server die Verbindung nach jeder seiner Antworten. Dies zwingt einen Client, der mehrere Anfragen stellen muss, um die verschiedenen Dokumente zu erhalten, aus denen eine Webseite besteht, bei jeder Anfrage eine neue Verbindung herzustellen, was mit Kosten verbunden ist. Beim Protokoll HTTP/1.1 kann der Client den Server anweisen, die Verbindung offen zu halten, bis er ihn auffordert, sie zu schließen. Er kann somit alle Dokumente einer Webseite über eine einzige Verbindung abrufen und die Verbindung selbst schließen, sobald das letzte Dokument empfangen wurde. Der Server erkennt diese Schließung und schließt die Verbindung ebenfalls.
Um den Datenaustausch zwischen einem Client und einem Webserver zu untersuchen, werden wir ein Tool namens curl verwenden. Curl ist eine Anwendung, mit der man als Client auf Internetdienste zugreifen kann, die verschiedene Protokolle unterstützen (DOS, FTP, TELNET, GOPHER, ...). curl ist unter der Adresse http://curl.haxx.se/ verfügbar. Hier laden wir vorzugsweise die Windows-Version „win32-nossl“ herunter, da die Version „win32-ssl“ zusätzliche DLLs benötigt, die nicht im curl-Paket enthalten sind. Dieses Paket enthält eine Reihe von Dateien, die lediglich in einen Ordner entpackt werden müssen, den wir fortan <curl> nennen werden. Dieser Ordner enthält eine ausführbare Datei namens [curl.exe]. Dies wird unser Client sein, um Webserver abzufragen. Öffnen wir ein DOS-Fenster und wechseln wir in den Ordner <curl>:
dos>dir curl.exe
22/03/2004 13:29 299 008 curl.exe
E:\curl2>curl
curl: try 'curl --help' for more information
dos>curl --help | more
Usage: curl [options...] <url>
Options: (H) means HTTP/HTTPS only, (F) means FTP only
-a/--append Append to target file when uploading (F)
-A/--user-agent <string> User-Agent to send to server (H)
--anyauth Tell curl to choose authentication method (H)
-b/--cookie <name=string/file> Cookie string or file to read cookies from (H)
--basic Enable HTTP Basic Authentication (H)
-B/--use-ascii Use ASCII/text transfer
-c/--cookie-jar <file> Write cookies to this file after operation (H)
....
Verwenden wir diese Anwendung, um einen Webserver abzufragen und den Datenaustausch zwischen Client und Server zu untersuchen. Wir befinden uns in folgender Situation:
Der Webserver kann beliebig sein. Wir möchten hier den Datenaustausch zwischen dem Web-Client „curl“ und dem Webserver untersuchen. Zuvor haben wir die folgende statische Seite HTML erstellt:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
die wir in einem Browser anzeigen:
Man sieht, dass die angeforderte URL „URL“ lautet: http://localhost/aspnet/chap1/statique1.html. Der Webserver ist also localhost (=lokaler Rechner) und der Port 80. Wenn man den Quelltext dieser Webseite (Ansicht/Quelltext) aufruft, findet man den ursprünglich erstellten Text wieder:
Verwenden wir nun unseren Client CURL, um denselben Text URL abzufragen:
dos>curl http://localhost/aspnet/chap1/statique1.html
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Wir sehen, dass der Webserver ihm eine Reihe von Textzeilen gesendet hat, die den Code HTML der angeforderten Seite darstellen. Wir haben zuvor erwähnt, dass die Antwort eines Webservers folgende Form hat:
Hier haben wir jedoch die Header HTTP nicht gesehen. Das liegt daran, dass [curl] diese standardmäßig nicht anzeigt. Mit der Option --include können sie angezeigt werden:
E:\curl2>curl --include http://localhost/aspnet/Kapitel1/statique1.html
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Mon, 22 Mar 2004 16:51:00 GMT
X-AspNet-Version: 1.1.4322
Cache-Control: public
ETag: "1C4102CEE8C6400:1C4102CFBBE2250"
Content-Type: text/html
Content-Length: 161
Connection: Close
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Der Server hat tatsächlich eine Reihe von HTTP-Headern gesendet, gefolgt von einer Leerzeile:
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Mon, 22 Mar 2004 16:51:00 GMT
X-AspNet-Version: 1.1.4322
Cache-Control: public
ETag: "1C4102CEE8C6400:1C4102CFBBE2250"
Content-Type: text/html
Content-Length: 161
Connection: Close
Der Server gibt an,
| |
Der Server identifiziert sich. In diesem Fall handelt es sich um einen Cassini-Server | |
Datum und Uhrzeit der Antwort | |
spezifischer Header des Cassini-Servers | |
gibt dem Client Hinweise darauf, ob er die an ihn gesendete Antwort zwischenspeichern darf. Das Attribut [public] teilt dem Client mit, dass er die Seite zwischenspeichern darf. Ein Attribut [no-cache] hätte dem Client mitgeteilt, dass er die Seite nicht zwischenspeichern darf. | |
... | |
Der Server gibt an, dass er Text im Format HTML (HTML) senden wird. | |
Anzahl der Bytes des Dokuments, das nach den Headern HTTP gesendet wird. Diese Zahl entspricht der Dateigröße in Bytes von essai1.html: | |
Der Server teilt mit, dass er die Verbindung nach dem Senden des Dokuments schließen wird |
Der Client empfängt diese Header HTTP und weiß nun, dass er 161 Bytes empfangen wird, die ein Dokument HTML darstellen. Der Server sendet diese 161 Bytes unmittelbar nach der Leerzeile, die das Ende der Header HTTP signalisierte:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Hier erkennt man die ursprünglich erstellte Datei HTML. Wäre unser Client ein Browser, würde er diese Textzeilen nach dem Empfang interpretieren, um dem Benutzer über die Tastatur die folgende Seite anzuzeigen:
Verwenden wir erneut unseren Client [curl], um dieselbe Ressource abzufragen, diesmal jedoch nur die Antwort-Header:
dos>curl --head http://localhost/aspnet/chap1/statique1.html
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:11:54 GMT
Cache-Control: public
ETag: "1C410A504D60680:1C410A58621AD3E"
Content-Type: text/html
Content-Length: 161
Connection: Close
Wir erhalten das gleiche Ergebnis wie zuvor, ohne das Dokument HTML. Nun rufen wir ein Bild sowohl mit einem Browser als auch mit dem generischen Client TCP auf. Zunächst mit einem Browser:
Die Datei univ01.gif ist 4052 Byte groß:
Verwenden wir nun den Client [curl]:
dos>curl --head http://localhost/aspnet/chap1/univ01.gif
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:18:44 GMT
Cache-Control: public
ETag: "1C410A6795D7500:1C410A6868B1476"
Content-Type: image/gif
Content-Length: 4052
Connection: Close
Im obigen Frage-Antwort-Zyklus sind folgende Punkte zu beachten:
| |
| |
|
2.6.3.2. Die Anfrage eines HTTP-Clients
Stellen wir uns nun folgende Frage: Wenn wir ein Programm schreiben wollen, das mit einem Webserver „kommuniziert“, welche Befehle muss es an den Webserver senden, um eine bestimmte Ressource abzurufen? In den vorherigen Beispielen haben wir gesehen, was der Client empfing, aber nicht, was der Client sendete. Wir werden die Option [--verbose] von curl verwenden, um auch zu sehen, was der Client an den Server sendet. Beginnen wir mit der Abfrage der statischen Seite:
dos>curl --verbose http://localhost/aspnet/chap1/statique1.html
* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80
> GET /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
< HTTP/1.1 200 OK
< Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
< Date: Tue, 23 Mar 2004 07:37:06 GMT
< Cache-Control: public
< ETag: "1C410A504D60680:1C410A58621AD3E"
< Content-Type: text/html
< Content-Length: 161
< Connection: Close
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
* Closing connection #0
Zunächst baut der Client [curl] eine TCP/IP-Verbindung zum Port 80 des Rechners „localhost“ (=127.0.0.1) auf
Sobald die Verbindung hergestellt ist, sendet er seine Anfrage HTTP. Diese besteht aus einer Reihe von Textzeilen, die mit einer Leerzeile enden:
GET /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Die Anfrage HTTP eines Web-Clients hat zwei Funktionen:
- die gewünschte Ressource anzugeben. Dies ist hier die Aufgabe der ersten Zeile GET
- Informationen über den anfragenden Client bereitzustellen, damit der Server seine Antwort gegebenenfalls an diesen speziellen Client-Typ anpassen kann.
Die oben vom Client gesendeten Zeilen [curl] haben folgende Bedeutung:
um eine bestimmte Ressource gemäß einer bestimmten Version des Protokolls HTTP anzufordern. Der Server sendet eine Antwort im Format HTTP, gefolgt von einer leeren Zeile und anschließend der angeforderten Ressource | |
um anzugeben, wer der Client ist | |
um (Protokoll HTTP 1.1) den Rechner und den Port des abgefragten Webservers anzugeben | |
hier, um anzugeben, dass der Client keinen Cache verwaltet. | |
Typen MIME zur Angabe der Dateitypen, die der Client verarbeiten kann |
Wiederholen wir den Vorgang mit der Option --head von [curl]:
dos>curl --verbose --head --output reponse.txt http://localhost/aspnet/chap1/statique1.html
* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80
> HEAD /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
< HTTP/1.1 200 OK
< Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
< Date: Tue, 23 Mar 2004 07:54:22 GMT
< Cache-Control: public
< ETag: "1C410A504D60680:1C410A58621AD3E"
< Content-Type: text/html
< Content-Length: 161
< Connection: Close
Wir beschränken uns hier auf die vom Kunden gesendeten HTTP-Header:
HEAD /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Nur der Befehl, der die Ressource anfordert, hat sich geändert. Anstelle eines Befehls GET gibt es nun einen Befehl HEAD. Dieser Befehl fordert, dass die Antwort des Servers auf die Header HTTP beschränkt bleibt und dass er die angeforderte Ressource nicht sendet. Der obige Screenshot zeigt die empfangenen Header HTTP nicht an. Diese wurden aufgrund der Option [--output reponse.txt] des Befehls [curl] in eine Datei geschrieben:
dos>more reponse.txt
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:54:22 GMT
Cache-Control: public
ETag: "1C410A504D60680:1C410A58621AD3E"
Content-Type: text/html
Content-Length: 161
Connection: Close
2.6.4. Fazit
Anhand einiger Beispiele haben wir die Struktur einer Anfrage eines Web-Clients und die Struktur der Antwort des Web-Servers darauf kennengelernt. Der Dialog erfolgt über das Protokoll HTTP, eine Reihe von Befehlen im Textformat, die zwischen den beiden Partnern ausgetauscht werden. Die Anfrage des Clients und die Antwort des Servers weisen beide die folgende Struktur auf:
Bei einer Anfrage (oft als „Request“ bezeichnet) des Clients fehlt der Teil [Document] meist. Dennoch ist es einem Client möglich, ein Dokument an den Server zu senden. Dies geschieht mit einem Befehl namens PUT. Die beiden üblichen Befehle zum Abrufen einer Ressource sind GET und POST. Letzterer wird etwas später vorgestellt. Mit dem Befehl HEAD können ausschließlich die Header von HTTP angefordert werden. Die Befehle GET und POST werden von browserbasierten Web-Clients am häufigsten verwendet.
Auf Anfrage eines Clients sendet der Server eine Antwort mit derselben Struktur. Die angeforderte Ressource wird im Abschnitt [Document] übermittelt, es sei denn, der Befehl des Clients lautete HEAD; in diesem Fall werden nur die Header HTTP gesendet.
2.7. Die Sprache HTML
Ein Webbrowser kann verschiedene Dokumente anzeigen, wobei das häufigste das Dokument HTML (HyperText Markup Language) ist. Dabei handelt es sich um einen Text, der mit Tags der Form <balise>texte</balise> formatiert ist. So wird der Text „<B>important</B>“ den wichtigen Text in Fettdruck anzeigen. Es gibt auch einzelne Tags wie das Tag „<hr>“, das eine horizontale Linie anzeigt. Wir werden hier nicht auf alle Tags eingehen, die in einem HTML-Text vorkommen können. Es gibt zahlreiche Programme, mit denen man eine Webseite erstellen kann, ohne eine einzige Zeile Code zu schreiben. Diese Tools generieren automatisch den Code eines Layouts, das mit der Maus und vordefinierten Steuerelementen erstellt wurde. So kann man (mit der Maus) eine Tabelle in die Seite einfügen und anschließend den von der Software generierten HTML-Code einsehen, um herauszufinden, welche Tags zur Definition einer Tabelle auf einer Webseite verwendet werden müssen. Einfacher geht es nicht. Außerdem sind Kenntnisse der Sprache HTML unerlässlich, da dynamische Webanwendungen den an die Web-Clients zu sendenden Code HTML selbst generieren müssen. Dieser Code wird programmgesteuert generiert, und man muss natürlich wissen, was generiert werden muss, damit der Client die gewünschte Webseite erhält.
Zusammenfassend lässt sich sagen, dass man keineswegs die gesamte Sprache HTML beherrschen muss, um mit der Webprogrammierung zu beginnen. Allerdings sind diese Kenntnisse notwendig und können durch die Verwendung von WYSIWYG-Software zur Erstellung von Webseiten wie Word, FrontPage, DreamWeaver und Dutzenden anderen erworben werden. Eine weitere Möglichkeit, die Feinheiten der Sprache HTML zu entdecken, besteht darin, im Internet zu stöbern und den Quellcode von Seiten anzuzeigen, die interessante und Ihnen noch unbekannte Funktionen aufweisen.
2.7.1. Ein Beispiel
Betrachten wir das folgende Beispiel, das mit FrontPage Express erstellt wurde, einem kostenlosen Tool, das im Lieferumfang des Internet Explorers enthalten ist. Der von Frontpage generierte Code wurde hier bereinigt. Dieses Beispiel zeigt einige Elemente, die in einem Webdokument vorkommen können, wie zum Beispiel:
- eine Tabelle
- ein Bild
- einen Link
Ein HTML-Dokument hat im Allgemeinen folgende Form:
Das gesamte Dokument wird von den Tags <html>...</html> umschlossen. Es besteht aus zwei Teilen:
- <head>...</head>: Dies ist der nicht sichtbare Teil des Dokuments. Er enthält Informationen für den Browser, der das Dokument anzeigen wird. Oft findet man hier das Tag <title>...</title>, das den Text festlegt, der in der Titelleiste des Browsers angezeigt wird. Außerdem können hier weitere Tags vorkommen, insbesondere solche, die die Schlüsselwörter des Dokuments definieren – Schlüsselwörter, die anschließend von Suchmaschinen verwendet werden. In diesem Teil können sich auch Skripte befinden, die meist in JavaScript oder VBScript geschrieben sind und vom Browser ausgeführt werden.
- <body-Attribute>...</body>: Dies ist der Teil, der vom Browser angezeigt wird. Die in diesem Teil enthaltenen Tags HTML geben dem Browser die „gewünschte“ visuelle Darstellung des Dokuments vor. Jeder Browser interpretiert diese Tags auf seine eigene Weise. Zwei Browser können daher ein und dasselbe Webdokument unterschiedlich darstellen. Dies ist in der Regel eine der Herausforderungen für Webdesigner.
Der Code HTML unseres Beispieldokuments lautet wie folgt:
<html>
<head>
<title>balises</title>
</head>
<body background="/images/standard.jpg">
<center>
<h1>Les balises HTML</h1>
<hr>
</center>
<table border="1">
<tr>
<td>cellule(1,1)</td>
<td valign="middle" align="center" width="150">cellule(1,2)</td>
<td>cellule(1,3)</td>
</tr>
<tr>
<td>cellule(2,1)</td>
<td>cellule(2,2)</td>
<td>cellule(2,3</td>
</tr>
</table>
<table border="0">
<tr>
<td>Une image</td>
<td><img border="0" src="/images/univ01.gif" width="80" height="95"></td>
</tr>
<tr>
<td>le site de l'ISTIA</td>
<td><a href="http://istia.univ-angers.fr">ici</a></td>
</tr>
</table>
</body>
</html>
Im Code wurden ausschließlich die Punkte hervorgehoben, die für uns von Interesse sind:
Element | Tags und Beispiele HTML |
<title>balises</title> balises erscheint in der Titelleiste des Browsers, der das Dokument anzeigt | |
<hr>: Zeigt einen horizontalen Strich an | |
<table-Attribute>....</table>: zum Definieren der Tabelle <tr Attribute>...</tr>: zum Definieren einer Zeile <td Attribute>...</td>: zum Definieren einer Zelle Beispiele: <table border="1">...</table>: Das Attribut „border“ legt die Dicke des Tabellenrandes fest <td valign="middle" align="center" width="150">Zelle(1,2)</td>: Definiert eine Zelle, deren Inhalt „Zelle(1,2)“ lautet. Dieser Inhalt wird vertikal (valign="middle") und horizontal (align="center") zentriert. Die Zelle hat eine Breite von 150 Pixeln (width="150") | |
<img border="0" src="/images/univ01.gif" width="80" height="95">: Definiert ein Bild ohne Rahmen („border=0“), mit einer Höhe von 95 Pixeln (height="95"), einer Breite von 80 Pixeln (width="80") und dessen Quelldatei sich unter /images/univ01.gif auf dem Webserver befindet (src="/images/univ01.gif"). Dieser Link befindet sich in einem Webdokument, das mit dem URL http://localhost:81/html/balises.htm erstellt wurde. Daher fordert der Browser die Datei URL http://localhost:81/images/univ01.gif an, um das hier referenzierte Bild zu erhalten. | |
<a href="http://istia.univ-angers.fr">hier</a>: bewirkt, dass der Text ici als Link zu URL http://istia.univ-angers.fr dient. | |
<body background="/images/standard.jpg">: Gibt an, dass sich das Bild, das als Seitenhintergrund dienen soll, unter URL /images/standard.jpg auf dem Webserver befindet. In unserem Beispiel fordert der Browser die URL URL http://localhost:81/images/standard.jpg an, um dieses Hintergrundbild abzurufen. |
An diesem einfachen Beispiel wird deutlich, dass der Browser drei Anfragen an den Server stellen muss, um das gesamte Dokument aufzubauen:
- http://localhost:81/html/balises.htm, um den Quellcode HTML des Dokuments abzurufen
- http://localhost:81/images/univ01.gif, um das Bild univ01.gif abzurufen
- http://localhost:81/images/standard.jpg, um das Hintergrundbild standard.jpg abzurufen
Das folgende Beispiel zeigt ein Webformular, das ebenfalls mit FrontPage erstellt wurde.
Der von FrontPage generierte und etwas bereinigte Code HTML lautet wie folgt:
<html>
<head>
<title>balises</title>
<script language="JavaScript">
function effacer(){
alert("Vous avez cliqué sur le bouton Effacer");
}//löschen
</script>
</head>
<body background="/images/standard.jpg">
<form method="POST" >
<table border="0">
<tr>
<td>Etes-vous marié(e)</td>
<td>
<input type="radio" value="Oui" name="R1">Oui
<input type="radio" name="R1" value="non" checked>Non
</td>
</tr>
<tr>
<td>Cases à cocher</td>
<td>
<input type="checkbox" name="C1" value="un">1
<input type="checkbox" name="C2" value="deux" checked>2
<input type="checkbox" name="C3" value="trois">3
</td>
</tr>
<tr>
<td>Champ de saisie</td>
<td>
<input type="text" name="txtSaisie" size="20" value="qqs mots">
</td>
</tr>
<tr>
<td>Mot de passe</td>
<td>
<input type="password" name="txtMdp" size="20" value="unMotDePasse">
</td>
</tr>
<tr>
<td>Boîte de saisie</td>
<td>
<textarea rows="2" name="areaSaisie" cols="20">
ligne1
ligne2
ligne3
</textarea>
</td>
</tr>
<tr>
<td>combo</td>
<td>
<select size="1" name="cmbValeurs">
<option>choix1</option>
<option selected>choix2</option>
<option>choix3</option>
</select>
</td>
</tr>
<tr>
<td>liste à choix simple</td>
<td>
<select size="3" name="lst1">
<option selected>liste1</option>
<option>liste2</option>
<option>liste3</option>
<option>liste4</option>
<option>liste5</option>
</select>
</td>
</tr>
<tr>
<td>liste à choix multiple</td>
<td>
<select size="3" name="lst2" multiple>
<option>liste1</option>
<option>liste2</option>
<option selected>liste3</option>
<option>liste4</option>
<option>liste5</option>
</select>
</td>
</tr>
<tr>
<td>bouton</td>
<td>
<input type="button" value="Effacer" name="cmdEffacer" onclick="effacer()">
</td>
</tr>
<tr>
<td>envoyer</td>
<td>
<input type="submit" value="Envoyer" name="cmdRenvoyer">
</td>
</tr>
<tr>
<td>rétablir</td>
<td>
<input type="reset" value="Rétablir" name="cmdRétablir">
</td>
</tr>
</table>
<input type="hidden" name="secret" value="uneValeur">
</form>
</body>
</html>
Die visuelle Überprüfung <--> Tag HTML ergibt Folgendes:
Prüfung | Tag HTML |
<form method="POST" > | |
<input type="text" name="txtSaisie" size="20" value="ein paar Wörter"> | |
<input type="password" name="txtMdp" size="20" value="unMotDePasse"> | |
<textarea rows="2" name="areaSaisie" cols="20"> Zeile 1 Zeile 2 Zeile 3 </textarea> | |
<input type="radio" value="Ja" name="R1">Ja <input type="radio" name="R1" value="nein" checked>Nein | |
<input type="checkbox" name="C1" value="eins">1 <input type="checkbox" name="C2" value="zwei" checked>2 <input type="checkbox" name="C3" value="drei">3 | |
<select size="1" name="cmbValeurs"> <option>Auswahl 1</option> <option selected>Auswahl 2</option> <option>Option 3</option> </select> | |
<select size="3" name="lst1"> <option selected>Liste1</option> <option>Liste 2</option> <option>Liste 3</option> <option>Liste 4</option> <option>Liste 5</option> </select> | |
<select size="3" name="lst2" multiple> <option>Liste1</option> <option>Liste 2</option> <option selected>Liste 3</option> <option>Liste 4</option> <option>Liste 5</option> </select> | |
<input type="submit" value="Senden" name="cmdRenvoyer"> | |
<input type="reset" value="Zurücksetzen" name="cmdRétablir"> | |
<input type="button" value="Löschen" name="cmdEffacer" onclick="effacer()"> |
Sehen wir uns diese verschiedenen Steuerelemente einmal genauer an.
2.7.1.1. Das Formular
<form method="POST" > |
<form name="..." method="..." action="...">...</form> | |
name="frmexemple": Name des Formulars method="..." : Methode, die vom Browser verwendet wird, um die im Formular erfassten Werte an den Webserver zu senden action="..." : URL, an die die im Formular erfassten Werte gesendet werden. Ein Webformular wird von den Tags <form>...</form> umschlossen. Das Formular kann einen Namen haben (name="xx"). Dies gilt für alle Steuerelemente, die in einem Formular vorkommen können. Dieser Name ist nützlich, wenn das Webdokument Skripte enthält, die auf Elemente des Formulars verweisen müssen. Der Zweck eines Formulars besteht darin, vom Benutzer über Tastatur oder Maus eingegebene Informationen zu sammeln und diese an eine URL des Webservers zu senden. An welche? An diejenige, die im Attribut action="URL" angegeben ist. Fehlt dieses Attribut, werden die Informationen an den Webserver des Dokuments gesendet, in dem sich das Formular befindet. Dies wäre im obigen Beispiel der Fall. Bislang haben wir den Web-Client immer als „Anfrager“ von Informationen bei einem Webserver betrachtet, niemals als „Lieferanten“ von Informationen an diesen. Wie kann ein Webclient Informationen (die im Formular enthaltenen) an einen Webserver übermitteln? Darauf werden wir etwas später noch näher eingehen. Er kann zwei verschiedene Methoden verwenden, die als POST und GET bezeichnet werden. Das Attribut method="méthode", dessen Methode entweder GET oder POST ist, des Tags <form> gibt dem Browser vor, welche Methode zum Senden der im Formular erfassten Informationen an die durch das Attribut action="URL" angegebene Adresse URL verwendet werden soll. Wenn das Attribut method nicht angegeben ist, wird standardmäßig die Methode GET verwendet. |
2.7.1.2. Eingabefeld
<input type="text" name="txtSaisie" size="20" value="ein paar Wörter"> <input type="password" name="txtMdp" size="20" value="unMotDePasse"> |
<input type="..." name="..." size=".." value=".."> Das `input`-Tag gibt es für verschiedene Steuerelemente. Das Attribut `type` dient dazu, diese verschiedenen Steuerelemente voneinander zu unterscheiden. | |
type="text": Gibt an, dass es sich um ein Eingabefeld handelt type="password": Die Zeichen im Eingabefeld werden durch *-Zeichen ersetzt. Dies ist der einzige Unterschied zum normalen Eingabefeld. Diese Art von Steuerelement eignet sich für die Eingabe von Passwörtern. size="20": Anzahl der im Feld sichtbaren Zeichen – verhindert nicht die Eingabe weiterer Zeichen name="txtSaisie": Name des Steuerelements value="ein paar Wörter": Text, der im Eingabefeld angezeigt wird. |
2.7.1.3. Mehrzeiliges Eingabefeld
<textarea rows="2" name="areaSaisie" cols="20"> ligne1 ligne2 ligne3 </textarea> |
<textarea ...>Text</textarea> zeigt ein mehrzeiliges Eingabefeld an, das zunächst mit Text gefüllt ist | |
rows="2": Anzahl der Zeilen cols="'20": Anzahl der Spalten name="areaSaisie": Name des Steuerelements |
2.7.1.4. Optionsfelder
<input type="radio" value="Ja" name="R1">Ja <input type="radio" name="R1" value="nein" checked>Nein |
<input type="radio" attribut2="Wert2" ....>Text zeigt ein Optionsfeld mit Text daneben an. | |
name="radio": Name des Steuerelements. Radiobuttons mit demselben Namen bilden eine Gruppe von sich gegenseitig ausschließenden Schaltflächen: Es kann immer nur einer davon ausgewählt werden. value="Wert": dem Optionsfeld zugewiesener Wert. Dieser Wert ist nicht mit dem Text zu verwechseln, der neben dem Optionsfeld angezeigt wird. Letzterer dient lediglich der Anzeige. checked: Ist dieses Schlüsselwort vorhanden, ist das Optionsfeld markiert, andernfalls nicht. |
2.7.1.5. Kontrollkästchen
<input type="checkbox" name="C1" value="eins">1 <input type="checkbox" name="C2" value="zwei" checked>2 <input type="checkbox" name="C3" value="drei">3 |
<input type="checkbox" attribut2="Wert2" ....>Text zeigt ein Kontrollkästchen mit Text daneben an. | |
name="C1": Name des Steuerelements. Kontrollkästchen können denselben Namen haben oder auch nicht. Kontrollkästchen mit demselben Namen bilden eine Gruppe zugehöriger Kontrollkästchen. value="Wert": dem Kontrollkästchen zugewiesener Wert. Dieser Wert ist nicht mit dem Text zu verwechseln, der neben dem Kontrollkästchen angezeigt wird. Letzterer dient lediglich der Anzeige. checked: Ist dieses Schlüsselwort vorhanden, ist das Optionsfeld aktiviert, andernfalls nicht. |
2.7.1.6. Dropdown-Liste (Combo)
<select size="1" name="cmbValeurs"> <option>choix1</option> <option selected>Auswahl 2</option> <option>choix3</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> zeigt die Texte zwischen den Tags <option>...</option> in einer Liste an | |
name="cmbValeurs": Name des Steuerelements. size="1": Anzahl der sichtbaren Listenelemente. size="1" macht die Liste zu einer Art Combobox. selected: Wenn dieses Schlüsselwort für ein Listenelement vorhanden ist, wird dieses in der Liste als ausgewählt angezeigt. In unserem obigen Beispiel erscheint das Listenelement choix2 als ausgewähltes Element der Combobox, wenn diese zum ersten Mal angezeigt wird. |
2.7.1.7. Liste mit Einzelauswahl
<select size="3" name="lst1"> <option selected>Liste1</option> <option>liste2</option> <option>liste3</option> <option>liste4</option> <option>liste5</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> zeigt die Texte zwischen den Tags <option>...</option> in einer Liste an | |
– dieselben wie bei der Dropdown-Liste, die nur ein Element anzeigt. Dieses Steuerelement unterscheidet sich von der vorherigen Dropdown-Liste lediglich durch sein Attribut „size>1“. |
2.7.1.8. Mehrfachauswahlliste
<select size="3" name="lst2" multiple> <option selected>Liste1</option> <option>liste2</option> <option selected>Liste 3</option> <option>liste4</option> <option>liste5</option> </select> |
<select size=".." name=".." multiple> <option [selected]>...</option> ... </select> zeigt die Texte zwischen den Tags <option>...</option> in einer Liste an | |
multiple: Ermöglicht die Auswahl mehrerer Elemente in der Liste. Im obigen Beispiel sind die Elemente liste1 und liste3 beide ausgewählt. |
2.7.1.9. Schaltfläche vom Typ „button“
<input type="button" value="Löschen" name="cmdEffacer" onclick="effacer()"> |
<input type="button" value="..." name="..." onclick="effacer()" ....> | |
type="button": Definiert ein Schaltfeld. Es gibt zwei weitere Schaltfeldtypen: submit und reset. value="Löschen": Der auf der Schaltfläche angezeigte Text onclick="Funktion()": Ermöglicht die Definition einer Funktion, die ausgeführt werden soll, wenn der Benutzer auf die Schaltfläche klickt. Diese Funktion ist Teil der im angezeigten Webdokument definierten Skripte. Die vorstehende Syntax entspricht der Syntax javascript. Wenn die Skripte in VBScript geschrieben sind, müsste man onclick="Funktion" ohne Klammern schreiben. Die Syntax bleibt identisch, wenn Parameter an die Funktion übergeben werden sollen: onclick="Funktion(val1, val2,...)" In unserem Beispiel ruft ein Klick auf die Schaltfläche Effacer die folgende JavaScript-Funktion effacer auf: Die Funktion effacer gibt folgende Meldung aus:  |
2.7.1.10. Schaltfläche vom Typ „Submit“
<input type="submit" value="Senden" name="cmdRenvoyer"> |
<input type="submit" value="Senden" name="cmdRenvoyer"> | |
type="submit": Definiert die Schaltfläche als Schaltfläche zum Senden der Formulardaten an den Webserver. Wenn der Benutzer auf diese Schaltfläche klickt, sendet der Browser die Formulardaten an die im Attribut „action“ des Tags <form> angegebene Adresse gemäß der im Attribut „method“ desselben Tags definierten Methode. value="Senden": Der auf der Schaltfläche angezeigte Text |
2.7.1.11. Schaltfläche vom Typ „Reset“
<input type="reset" value="Zurücksetzen" name="cmdRétablir"> |
<input type="reset" value="Zurücksetzen" name="cmdRétablir"> | |
type="reset": Definiert die Schaltfläche als Schaltfläche zum Zurücksetzen des Formulars. Wenn der Benutzer auf diese Schaltfläche klickt, versetzt der Browser das Formular in den Zustand zurück, in dem es empfangen wurde. value="Zurücksetzen": Der auf der Schaltfläche angezeigte Text |
2.7.1.12. Verstecktes Feld
<input type="hidden" name="secret" value="uneValeur"> |
<input type="hidden" name="..." value="..."> | |
type="hidden": Gibt an, dass es sich um ein verstecktes Feld handelt. Ein verstecktes Feld ist Teil des Formulars, wird dem Benutzer jedoch nicht angezeigt. Würde der Benutzer jedoch in seinem Browser den Quellcode anzeigen lassen, würde er das Tag <input type="hidden" value="..."> und somit den Wert des versteckten Feldes sehen. value="einWert": Wert des versteckten Feldes. Wozu dient das versteckte Feld? Es ermöglicht dem Webserver, Informationen über mehrere Anfragen eines Kunden hinweg zu speichern. Betrachten wir eine Online-Shopping-Anwendung. Der Kunde kauft auf einer ersten Seite eines Katalogs einen ersten Artikel art1 in der Menge q1 und wechselt dann zu einer neuen Seite des Katalogs. Um zu speichern, dass der Kunde q1 Artikel art1 gekauft hat, kann der Server diese beiden Informationen in ein verstecktes Feld des Webformulars auf der neuen Seite einfügen. Auf dieser neuen Seite kauft der Kunde die Artikel q2 und art2. Wenn die Daten dieses zweiten Formulars an den Server gesendet werden (Submit), erhält dieser nicht nur die Informationen (q2, art2), sondern auch (q1, art1), die ebenfalls Teil des Formulars als verstecktes Feld sind, das vom Benutzer nicht geändert werden kann. Der Webserver wird dann die Informationen (q1,art1) und (q2,art2) in ein neues verstecktes Feld einfügen und eine neue Katalogseite senden. Und so weiter. |
2.7.2. Übermittlung der Werte eines Formulars von einem Web-Client an einen Webserver
In der vorherigen Studie haben wir erwähnt, dass der Web-Client über zwei Methoden verfügt, um die Werte eines von ihm angezeigten Formulars an einen Webserver zu senden: die Methoden GET und POST. Sehen wir uns anhand eines Beispiels den Unterschied zwischen den beiden Methoden an. Die zuvor untersuchte Seite ist eine statische Seite. Um Zugriff auf die vom Browser gesendeten HTTP-Header zu erhalten, der dieses Dokument anfordert, wandeln wir sie in eine dynamische Seite für einen Webserver .NET (IIS oder Cassini) um. Hier geht es nicht um die .NET-Technologie, die im nächsten Kapitel behandelt wird, sondern um den Client-Server-Austausch. Der Code der Seite ASP.NET lautet wie folgt:
<%@ Page Language="vb" CodeBehind="params.aspx.vb" AutoEventWireup="false" Inherits="ConsoleApplication1.params" %>
<script runat="server">
Private Sub Page_Init(Byval Sender as Object, Byval e as System.EventArgs)
' Die Abfrage wird gespeichert
saveRequest
end sub
Private Sub saveRequest
' speichert die aktuelle Anfrage unter request.txt im Seitenordner
dim requestFileName as String=Me.MapPath(Me.TemplateSourceDirectory)+"\request.txt"
Me.Request.SaveAs(requestFileName,true)
end sub
</script>
<html>
<head>
<title>balises</title>
<script language="JavaScript">
function effacer(){
alert("Vous avez cliqué sur le bouton Effacer");
}//löschen
</script>
</head>
<body background="/images/standard.jpg">
....
</body>
</html>
Zum Inhalt HTML der untersuchten Seite fügen wir einen Codeabschnitt in VB.NET hinzu. Wir werden diesen Code nicht näher erläutern, außer um darauf hinzuweisen, dass der Webserver bei jedem Aufruf des oben genannten Dokuments die Anfrage des Webclients in der Datei [request.txt] im Ordner des aufgerufenen Dokuments speichert.
2.7.2.1. Methode GET
Führen wir einen ersten Test durch, bei dem im Code HTML des Dokuments das Tag FORM wie folgt definiert ist:
<form method="get">
Das vorherige Dokument (HTML + Code VB) wird als [params.aspx] aufgerufen. Es wird in der Verzeichnisstruktur eines Webservers unter .NET (IIS/Cassini) abgelegt und über die URL http://localhost/aspnet/chap1/params.aspx aufgerufen:
Der Browser hat soeben eine Anfrage gestellt, und wir wissen, dass diese in der Datei [request.txt] gespeichert wurde. Sehen wir uns deren Inhalt an:
GET /aspnet/chap1/params.aspx HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0,1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Wir finden Elemente wieder, die wir bereits beim Client [curl] gesehen haben. Andere tauchen zum ersten Mal auf:
Der Client fordert den Server auf, die Verbindung nach seiner Antwort nicht zu schließen. So kann er dieselbe Verbindung für eine spätere Anfrage nutzen. Die Verbindung bleibt jedoch nicht unbegrenzt offen. Der Server schließt sie nach einer zu langen Zeit der Inaktivität. | |
Dauer in Sekunden, während der die Verbindung [Keep-Alive] offen bleibt | |
Zeichenkategorie, die der Client verarbeiten kann | |
Liste der vom Kunden bevorzugten Sprachen. |
Wir füllen das Formular wie folgt aus:
Wir verwenden die Schaltfläche [Envoyer] oben. Ihr Code HTML lautet wie folgt:
Beim Klicken auf eine Schaltfläche vom Typ [Submit] sendet der Browser die Formularparameter (Tag <form>) an die im Attribut [action] des Tags <form action="URL"> angegebene Adresse URL, sofern diese existiert. Wenn dieses Attribut nicht vorhanden ist, werden die Formularparameter an die URL URL gesendet, von der das Formular bereitgestellt wurde. Dies ist hier der Fall. Die Schaltfläche „[Envoyer]“ sollte daher eine Anfrage des Browsers an die Seite „URL“ mit einer Übergabe der Formularparameter auslösen. Da die Seite [params.aspx] die empfangene Anfrage speichert, sollten wir wissen, wie der Client diese Parameter übertragen hat. Versuchen wir es. Wir klicken auf die Schaltfläche [Envoyer]. Wir erhalten die folgende Antwort vom Browser:
Das ist die Startseite, aber man kann feststellen, dass sich der Wert „URL“ im Feld „[Adresse]“ des Browsers geändert hat. Er lautet nun wie folgt:
http://localhost/aspnet/chap1/params.aspx?R1=Ja&C1=eins&C2=zwei&txtSaisie=Webprogrammierung&txtMdp=das+ist+geheim&areaSaisie=die+Grundlagen+der%0D%0AWebprogrammierung&cmbValeurs=Auswahl3&lst1=Liste3&lst2=Liste1&lst2=Liste3&cmdRenvoyer=Senden&secret=uneValeur
Man stellt fest, dass die im Formular getroffenen Auswahlen im „URL“ wiederzufinden sind. Sehen wir uns den Inhalt der Datei „[request.txt]“ an, in der die Anfrage des Clients gespeichert wurde:
GET /aspnet/chap1/params.aspx?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0,1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
Referer: http://localhost/aspnet/chap1/params.aspx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Es handelt sich um eine Anfrage mit dem Code HTTP, die der ursprünglichen Anfrage des Browsers sehr ähnlich ist, als dieser das Dokument ohne Übermittlung von Parametern angefordert hatte. Es gibt zwei Unterschiede:
Die Formularparameter wurden hinter der Dokument-ID URL in der Form ?param1=val1¶m2=val2&... hinzugefügt. | |
Der Client gibt mit diesem Header „HTTP“ die Dokument-ID „URL“ an, die er bei der Anfrage angezeigt hat |
Schauen wir uns genauer an, wie die Parameter im Befehl GET URL?param1=Wert1¶m2=Wert2&... übergeben wurden HTTP/1.1, wobei die parami die Namen der Steuerelemente des Webformulars und die Werte die ihnen zugeordneten Werte sind. Nachfolgend stellen wir eine Tabelle mit drei Spalten vor:
- Spalte 1: enthält die Definition eines Steuerelements HTML aus dem Beispiel
- Spalte 2: zeigt die Darstellung dieses Steuerelements in einem Browser
- Spalte 3: zeigt den Wert an, den der Browser für das Steuerelement aus Spalte 1 an den Server sendet, und zwar in der Form, wie er in der Anfrage „GET“ aus dem Beispiel vorliegt
Steuerelement HTML | Anzeige | zurückgegebene(r) Wert(e) |
<input type="radio" value="Ja" name="R1">Ja <input type="radio" name="R1" value="nein" checked>Nein |  | R1=Ja – der Wert des Attributs value des vom Benutzer markierten Optionsfelds. |
<input type="checkbox" name="C1" value="eins">1 <input type="checkbox" name="C2" value="zwei" checked>2 <input type="checkbox" name="C3" value="drei">3 |  | C1=eins C2=zwei – Werte der Attribute value der vom Benutzer angekreuzten Kontrollkästchen |
<input type="text" name="txtSaisie" size="20" value="einige Wörter"> |  | txtEingabe=Webprogrammierung - vom Benutzer in das Eingabefeld eingegebener Text. Leerzeichen wurden durch das Zeichen + ersetzt |
<input type="password" name="txtMdp" size="20" value="unMotDePasse"> |  | txtMdp=diesistgeheim - vom Benutzer in das Eingabefeld eingegebener Text |
<textarea rows="2" name="areaSaisie" cols="20"> Zeile 1 Zeile 2 Zeile 3 </textarea> |  | Eingabefeld=Grundlagen+der%0D%0A Webprogrammierung%0D%0A – vom Benutzer in das Eingabefeld eingegebener Text. %OD%OA ist das Zeichen für das Zeilenende. Leerzeichen wurden durch das Pluszeichen ersetzt |
<select size="1" name="cmbValeurs"> <option>Auswahl1</option> <option selected>Auswahl 2</option> <option>Auswahl 3</option> </select> |  | cmbValeurs=Auswahl3 – vom Benutzer in der Liste mit einer Auswahl ausgewählter Wert |
<select size="3" name="lst1"> <option selected>Liste1</option> <option>Liste2</option> <option>Liste3</option> <option>Liste4</option> <option>Liste 5</option> </select> |  | lst1=liste3 - vom Benutzer in der Liste mit einer Auswahl gewählter Wert |
<select size="3" name="lst2" multiple> <option selected>Liste1</option> <option>Liste2</option> <option selected>Liste3</option> <option>Liste 4</option> <option>Liste 5</option> </select> |  | lst2=Liste1 lst2=Liste3 - vom Benutzer in der Mehrfachauswahlliste ausgewählte Werte |
<input type="submit" value="Senden" name="cmdRenvoyer"> | cmdRenvoyer=Senden - Name und Attribut „value“ der Schaltfläche, mit der die Formulardaten an den Server gesendet wurden | |
<input type="hidden" name="secret" value="uneValeur"> | secret=einWert - Attribut value des versteckten Feldes |
Man könnte sich fragen, was der Server mit den übergebenen Parametern gemacht hat. Eigentlich gar nichts. Beim Empfang des Befehls
GET /aspnet/chap1/params.aspx?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
hat der Webserver die Parameter an das Dokument http://localhost/aspnet/chap1/params.aspx weitergeleitet, URL an das Dokument, das wir ursprünglich erstellt haben. Wir haben keinen Code geschrieben, um die vom Client gesendeten Parameter abzurufen und zu verarbeiten. Daher läuft alles so ab, als ob die Anfrage des Clients einfach lauten würde:
Aus diesem Grund haben wir als Antwort auf unsere Schaltfläche [Envoyer] dieselbe Seite erhalten wie ursprünglich bei der Anfrage nach URL und [http://localhost/aspnet/chap1/params.aspx] ohne Parameter.
2.7.2.2. Methode POST
Das Dokument HTML ist nun so programmiert, dass der Browser die Methode POST verwendet, um die Formularwerte an den Webserver zu senden:
Wir rufen das neue Dokument über URL [http://localhost/aspnet/chap1/params.aspx] auf, füllen das Formular wie bei der Methode GET aus und übermitteln die Parameter mit der Schaltfläche [Envoyer] an den Server. Wir erhalten vom Server die folgende Antwortseite:
Wir erhalten also dasselbe Ergebnis wie bei den Methoden GET und c.a.d: die Startseite. Es fällt ein Unterschied auf: Im Feld [Adresse] des Browsers werden die übermittelten Parameter nicht angezeigt. Sehen wir uns nun die vom Client gesendete Anfrage an, die in der Datei [request.txt] gespeichert wurde:
POST /aspnet/chap1/params.aspx HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Content-Length: 210
Content-Type: application/x-www-form-urlencoded
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0,1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
Referer: http://localhost/aspnet/chap1/params.aspx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecrey&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur
In der Abfrage HTTP des Kunden tauchen neue Einträge auf:
Die Abfrage GET wurde durch die Abfrage POST ersetzt. Die Parameter sind in dieser ersten Zeile der Abfrage nicht mehr vorhanden. Man kann feststellen, dass sie nun nach einer Leerzeile hinter der Abfrage HTTP stehen. Ihre Kodierung ist identisch mit derjenigen, die sie in der Abfrage GET hatten. | |
Anzahl der „gesendeten“ Zeichen, c.a.d. Die Anzahl der Zeichen, die der Webserver nach dem Empfang der Header HTTP lesen muss, um das vom Client gesendete Dokument abzurufen. Bei dem betreffenden Dokument handelt es sich hier um die Liste der Formularwerte. | |
gibt den Typ des Dokuments an, das der Client nach den Headern HTTP sendet. Der Typ [application/x-www-form-urlencoded] gibt an, dass es sich um ein Dokument handelt, das Formularwerte enthält. |
Es gibt zwei Methoden, um Daten an einen Webserver zu übermitteln: GET und POST. Gibt es eine Methode, die besser ist als die andere? Wir haben gesehen, dass, wenn die Werte eines Formulars vom Browser mit der Methode GET gesendet wurden, der Browser in seinem Feld Adresse die angeforderte URL in der Form URL?param1=val1¶m2=val2&... anzeigt. Man kann dies als Vorteil oder als Nachteil betrachten:
- ein Vorteil, wenn man dem Benutzer ermöglichen möchte, diese konfigurierte URL in seine Lesezeichen aufzunehmen
- ein Nachteil, wenn man nicht möchte, dass der Benutzer Zugriff auf bestimmte Informationen des Formulars hat, wie zum Beispiel versteckte Felder
Im weiteren Verlauf werden wir in unseren Formularen fast ausschließlich die Methode POST verwenden.
2.8. Conclusion
In diesem Kapitel wurden verschiedene Grundkonzepte der Webentwicklung vorgestellt:
- die verschiedenen verfügbaren Werkzeuge und Technologien (Java, ASP, asp.net, PHP, Perl, VBScript, JavaScript)
- den Client-Server-Austausch über das Protokoll HTTP
- die Gestaltung eines Dokuments mithilfe der Sprache HTML
- die Gestaltung von Eingabeformularen
Anhand eines Beispiels haben wir gesehen, wie ein Client Informationen an den Webserver senden kann. Wir haben jedoch nicht gezeigt, wie der Server
- diese Informationen abrufen
- diese verarbeiten
- dem Kunden eine dynamische Antwort senden, die vom Ergebnis der Verarbeitung abhängt
Dies ist der Bereich der Webprogrammierung, den wir im folgenden Kapitel mit der Vorstellung der Technologie ASP.NET behandeln.