2. Die Grundlagen
In diesem Kapitel stellen wir die Grundlagen der Webprogrammierung vor. Das Hauptziel besteht darin, die wichtigsten Prinzipien der Webprogrammierung vorzustellen, bevor sie in der Praxis mit einer bestimmten Sprache und Umgebung angewendet werden. Es enthält zahlreiche Beispiele, die Sie ausprobieren sollten, um die Philosophie der Webentwicklung nach und nach zu „verinnerlichen“.
2.1. Die Komponenten einer Webanwendung
 |
Nummer | Rolle | Häufige Beispiele |
Server-Betriebssystem | Linux, Windows | |
Webserver | Apache (Linux, Windows) IIS (NT), PWS (Win9x) | |
Serverseitige Skripte. Sie können von Servermodulen oder von Programmen außerhalb des Servers (CGI) ausgeführt werden. | 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 befinden wie das Programm, das sie nutzt, oder über das Internet auf einem anderen Rechner. | Oracle (Linux, Windows) MySQL (Linux, Windows) Access (Windows) SQL Server (Windows) | |
Client-Betriebssystem | Linux, Windows | |
Webbrowser | Netscape, Internet Explorer | |
Skripte, die auf der Client-Seite im Browser ausgeführt werden. Diese Skripte haben keinen Zugriff auf die Festplatten des Client-Computers. | VBScript (IE) JavaScript (IE, Netscape) PerlScript (IE) Java-Applets |
2.2. Datenaustausch in einer Webanwendung mit einem Formular
 |
Nummer | Rolle |
Der Browser fordert zum ersten Mal eine URL an (http://machine/url). Es werden keine Parameter übergeben. | |
Der Webserver sendet die Webseite für diese URL. Sie kann statisch sein oder dynamisch durch ein serverseitiges Skript (SA) generiert werden, das möglicherweise Inhalte aus Datenbanken (SB, SC) verwendet hat. Hier erkennt das Skript, dass die URL ohne Parameter angefordert wurde, und generiert die ursprüngliche Webseite. Der Browser empfängt die Seite und zeigt sie an (CA). Browserseitige Skripte (CB) haben die vom Server gesendete Startseite möglicherweise verändert. Durch Interaktionen zwischen dem Benutzer (CD) und den Skripten (CB) wird die Webseite dann verändert. Insbesondere werden Formulare ausgefüllt. | |
Der Benutzer übermittelt die Formulardaten, die anschließend an den Webserver gesendet werden müssen. Der Browser fordert die ursprüngliche URL oder gegebenenfalls eine andere an und überträgt gleichzeitig die Formularwerte an den Server. Hierfür stehen zwei Methoden zur Verfügung: GET und POST. Nach Erhalt der Client-Anfrage löst der Server das mit der angeforderten URL verknüpfte Skript (SA) aus, das die Parameter erkennt und verarbeitet. | |
Der Server liefert die vom Programm (SA, SB, SC) generierte Webseite aus. Dieser Schritt ist identisch mit dem vorherigen Schritt 2. Die Kommunikation verläuft nun gemäß den Schritten 2 und 3. |
2.3. Einige Ressourcen
Nachfolgend finden Sie eine Liste mit Ressourcen zur Installation und Verwendung bestimmter Tools für die Webentwicklung. Ein Anhang enthält Anleitungen zur Installation dieser Tools.
- Apache: Installation und Implementierung, O'Reilly | |
- Programmieren in Perl, Larry Wall, O'Reilly - CGI-Anwendungen in Perl, Neuss und Vromans, O'Reilly - die in Active Perl enthaltene HTML-Dokumentation | |
- Webprogrammierung mit PHP, Lacroix, Eyrolles - PHP-Benutzerhandbuch auf der PHP-Website verfügbar | |
- Schnittstelle zwischen Web und Datenbanken unter WinNT, Alex Homer, Eyrolles | |
- JAVA Servlets, Jason Hunter, O'Reilly - Netzwerkprogrammierung mit Java, Elliotte Rusty Harold, O'Reilly - JDBC und Java, George Reese, O'Reilly | |
- Das MySQL-Handbuch ist auf der MySQL-Website verfügbar - Oracle 8i unter Linux, Gilles Briard, Eyrolles - Oracle 8i unter NT, Gilles Briard, Eyrolles |
2.4. Notationen
Im Folgenden gehen wir davon aus, dass eine Reihe von Tools installiert wurde, und verwenden die folgende Notation:
Notation | Bedeutung |
Stammverzeichnis der Apache-Server-Verzeichnisstruktur | |
Stammverzeichnis der von Apache bereitgestellten Webseiten. Webseiten müssen sich unter diesem Stammverzeichnis befinden. Somit entspricht die URL http://localhost/page1.htm der Datei <apache-DocumentRoot>\page1.htm. | |
Stammverzeichnis des Verzeichnisbaums, der mit dem Alias cgi-bin verknüpft ist und in dem CGI-Skripte für Apache abgelegt werden können. Somit entspricht die URL http://localhost/cgi-bin/test1.pl der Datei <apache-cgi-bin>\test1.pl. | |
Stammverzeichnis der von PWS bereitgestellten Webseiten. Webseiten müssen sich unter diesem Stammverzeichnis befinden. Somit entspricht die URL http://localhost/page1.htm der Datei <pws-DocumentRoot>\page1.htm. | |
Stammverzeichnis des Perl-Verzeichnisbaums. Die ausführbare Datei perl.exe befindet sich normalerweise in <perl>\bin. | |
Stammverzeichnis des PHP-Verzeichnisbaums. Die ausführbare Datei php.exe befindet sich normalerweise in <php>. | |
Stammverzeichnis der Java-Verzeichnisstruktur. Java-bezogene ausführbare Dateien befinden sich in <java>\bin. | |
Stammverzeichnis des Tomcat-Servers. Beispiele für Servlets finden Sie unter <tomcat>\webapps\examples\servlets und Beispiele für JSP-Seiten unter <tomcat>\webapps\examples\jsp |
Für jedes dieser Tools finden Sie im Anhang Installationsanweisungen.
2.5. Statische Webseiten, dynamische Webseiten
Eine statische Seite wird durch eine HTML-Datei dargestellt. Eine dynamische Seite hingegen wird vom Webserver „on the fly“ generiert. In diesem Abschnitt stellen wir verschiedene Tests mit unterschiedlichen Webservern und Programmiersprachen vor, um die Universalität des Webkonzepts zu demonstrieren.
2.5.1. Statische HTML-Seite (HyperText Markup Language)
Betrachten Sie 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
- Starten Sie den Apache-Server
- Legen Sie das Skript test1.html in <apache-DocumentRoot> ab
- Rufe die URL http://localhost/essai1.html in einem Browser auf
- Stoppen Sie den Apache-Server
test2
- Starten Sie den PWS-Server
- Legen Sie das Skript test1.html in <pws-DocumentRoot> ab
- Rufen Sie die URL http://localhost/essai1.html in einem Browser auf
2.5.2. Eine ASP-Seite (Active Server Pages)
Das Skript test2.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 PWS-Server
- Legen Sie das Skript essai2.asp in <pws-DocumentRoot> ab
- Rufen Sie die URL http://localhost/essai2.asp mit einem Browser auf
2.5.3. Ein PERL-Skript (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 ist der Pfad zur ausführbaren Datei „perl.exe“. Passen Sie ihn bei Bedarf an. Sobald das Skript von einem Webserver ausgeführt wird, generiert es die folgende Seite:
Der Test
- Webserver: Apache
- Sehen Sie sich zur Orientierung die Konfigurationsdatei srm.conf oder httpd.conf (je nach Ihrer Apache-Version) im Verzeichnis <apache>\confs an und suchen Sie nach der Zeile, in der cgi-bin erwähnt wird, um das Verzeichnis <apache-cgi-bin> zu ermitteln, in dem Sie essai3.pl ablegen sollten.
- Legen Sie das Skript essai3.pl im Verzeichnis <apache-cgi-bin> ab
- Rufen Sie die URL http://localhost/cgi-bin/essai3.pl auf
Beachten Sie, dass das Laden der Perl-Seite länger dauert als das der ASP-Seite. Das liegt daran, dass das Perl-Skript von einem Perl-Interpreter ausgeführt wird, der erst geladen werden muss, bevor er das Skript ausführen kann. Er verbleibt nicht dauerhaft im Speicher.
2.5.4. Ein PHP-Skript (Personal Home Page, HyperText Processor)
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 vorstehende Skript erzeugt die folgende Webseite:
Tests
-
Überprüfen Sie die Konfigurationsdatei srm.conf oder die httpd.conf von Apache im Verzeichnis <Apache>\confs
-
Überprüfen Sie zur Orientierung die PHP-Konfigurationszeilen
test1
-
Starten Sie den Apache-Server
-
Legen Sie die Datei essai4.php im Verzeichnis <apache-DocumentRoot> ab
-
Rufen Sie die URL http://localhost/essai4.php auf
test2
-
Starten Sie den PWS-Server
-
Überprüfen Sie zur Sicherheit die PWS-Konfiguration in Bezug auf PHP
-
Legen Sie die Datei essai4.php im Verzeichnis <pws-DocumentRoot>\php ab
-
Rufen Sie die URL http://localhost/essai4.php auf
2.5.5. Ein JSP-Skript (Java Server Pages)
Das Skript heure.jsp
<% //programme Java affichant l'heure %>
<%@ page import="java.util.*" %>
<%
// code JAVA pour calculer l'heure
Calendar calendrier=Calendar.getInstance();
int heures=calendrier.get(Calendar.HOUR_OF_DAY);
int minutes=calendrier.get(Calendar.MINUTE);
int secondes=calendrier.get(Calendar.SECOND);
// heures, minutes, secondes sont des variables globales
// qui pourront être utilisées dans le code HTML
%>
<% // 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>
Sobald dieses Skript vom Webserver ausgeführt wird, erzeugt es die folgende Seite:
Tests
- Legen Sie das Skript heure.jsp in <tomcat>\jakarta-tomcat\webapps\examples\jsp (Tomcat 3.x) oder in <tomcat>\webapps\examples\jsp (Tomcat 4.x) ab
- Starten Sie den Tomcat-Server
- Rufen Sie die URL http://localhost:8080/examples/jsp/heure.jsp auf
2.5.6. Fazit
Die vorangegangenen Beispiele haben gezeigt, dass:
- eine HTML-Seite dynamisch durch ein Programm generiert werden kann. Das ist der Kern der Webprogrammierung.
- die verwendeten Sprachen und Webserver variieren können. Derzeit lassen sich folgende Haupttrends beobachten:
- die Kombinationen Apache/PHP (Windows, Linux) und IIS/PHP (Windows)
- ASP.NET-Technologie auf Windows-Plattformen, die den IIS-Server mit einer .NET-Sprache (C#, VB.NET usw.) kombiniert
- Java-Servlet-Technologie und JSP-Seiten, die auf verschiedenen Servern (Tomcat, Apache, IIS) und auf verschiedenen Plattformen (Windows, Linux) laufen. Genau diese Technologie wird in diesem Dokument näher erläutert.
2.6. Browserseitige Skripte
Eine HTML-Seite kann Skripte enthalten, die vom Browser ausgeführt werden. Es gibt viele browserspezifische 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.6.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 obige HTML-Seite enthält nicht nur HTML-Code, sondern auch ein Programm, das vom Browser ausgeführt werden soll, der diese Seite lädt. Der Code lautet wie folgt:
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
Die Tags <script> und </script> dienen dazu, Skripte innerhalb einer HTML-Seite abzugrenzen. Diese Skripte können in verschiedenen Sprachen geschrieben sein, und das Attribut language des Tags <script> gibt die verwendete Sprache an. In diesem Fall handelt es sich um VBScript. Wir werden nicht näher auf diese Sprache eingehen. Das obige Skript definiert eine Funktion namens „react“, die eine Meldung anzeigt. Wann wird diese Funktion aufgerufen? Die folgende Zeile HTML-Code gibt Aufschluss darüber:
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, erscheint die folgende Seite:
Tests
Nur der Internet Explorer (IE) ist in der Lage, VBScript-Skripte auszuführen. Netscape benötigt hierfür Add-ons. Wir können die folgenden Tests durchführen:
test1
- Apache-Server
- vbs1.html-Skript in <apache-DocumentRoot>
- Rufen Sie die URL http://localhost/vbs1.html mit dem Internet Explorer auf
test2
- PWS-Server
- vbs1.html-Skript in <pws-DocumentRoot>
- Rufen Sie die URL http://localhost/vbs1.html mit Internet Explorer auf
2.6.2. Eine Webseite mit einem JavaScript-Skript auf der Browserseite
Die Seite: 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>
Dies entspricht der vorherigen Seite, außer dass wir VBScript durch JavaScript ersetzt haben. JavaScript hat den Vorteil, dass es sowohl von Internet Explorer als auch von Netscape unterstützt wird. Die Ausführung führt zu denselben Ergebnissen:
Die Tests
test1
- Apache-Server
- Skript js1.html in <apache-DocumentRoot>
- Rufen Sie die URL http://localhost/js1.html mit dem IE- oder Netscape-Browser auf
test2
- PWS-Server
- Skript „js1.html“ in <pws-DocumentRoot>
- Rufen Sie die URL http://localhost/js1.html mit Internet Explorer oder Netscape auf
2.7. Client-Server-Kommunikation
Kehren wir zu unserem ursprünglichen Diagramm zurück, das die Komponenten einer Webanwendung veranschaulicht:
 |
Hier konzentrieren wir uns auf den Datenaustausch zwischen dem Client-Rechner und dem Server-Rechner. Dieser findet über ein Netzwerk statt, und es lohnt sich, die allgemeine Struktur des Datenaustauschs zwischen zwei entfernten Rechnern noch einmal zu betrachten.
2.7.1. Das OSI-Modell
Das offene Netzwerkmodell, bekannt als OSI (Open Systems Interconnection Reference Model), das von der ISO (Internationale Organisation für Normung) definiert wurde, 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 der darüberliegenden Schicht ihre eigenen Dienste zur Verfügung. Angenommen, zwei Anwendungen auf verschiedenen Rechnern A und B möchten miteinander kommunizieren: Dies geschieht auf der Anwendungsschicht. Sie müssen nicht alle Details der Netzwerkfunktion kennen: Jede Anwendung leitet die Informationen, die sie übertragen möchte, an die darunterliegende Schicht weiter: die Präsentationsschicht. Die Anwendung muss daher nur die Regeln für die Schnittstelle zur Präsentationsschicht kennen. Sobald sich die Informationen in der Präsentationsschicht befinden, werden sie gemäß anderen Regeln an die Sitzungsschicht weitergeleitet und so weiter, bis die Informationen das physikalische Medium erreichen und physikalisch an den Zielrechner übertragen werden. Dort durchläuft sie den umgekehrten Prozess dessen, was auf dem sendenden Rechner stattgefunden hat.
Auf jeder Schicht sendet der für die Übertragung 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 Schichtprotokoll bezeichnet werden. Wir erhalten somit das folgende endgültige Kommunikationsdiagramm:
 |
Die Aufgaben der verschiedenen Schichten sind wie folgt:
Gewährleistet die Übertragung von Bits über ein physikalisches Medium. Diese Schicht umfasst Datenverarbeitungsendgeräte (DPTE) wie Terminals oder Computer sowie Datenkreisabschlussgeräte (DCTE) wie Modulatoren/Demodulatoren, Multiplexer und Konzentratoren. Wichtige Punkte auf dieser Ebene sind: . die Wahl der Informationskodierung (analog oder digital) . die Wahl des Übertragungsmodus (synchron oder asynchron). | |
Verbirgt die physikalischen Eigenschaften der physikalischen Schicht. Erkennt und korrigiert Übertragungsfehler. | |
Verwaltet den Weg, den über das Netzwerk gesendete Informationen zurücklegen müssen. Dies wird als Routing bezeichnet: die Bestimmung der Route, die Informationen nehmen müssen, um ihr Ziel zu erreichen. | |
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 Multiplexing sein: Die Transportschicht kann eine einzige Netzwerkverbindung (von Rechner zu Rechner) nutzen, um Daten mehrerer Anwendungen zu übertragen. | |
Diese Schicht stellt Dienste bereit, die es einer Anwendung ermöglichen, eine Arbeitssitzung auf einem Remote-Rechner zu eröffnen und aufrechtzuerhalten. | |
Sie zielt darauf ab, die Darstellung von Daten über verschiedene Rechner hinweg zu standardisieren. Daher werden Daten, die von Rechner A stammen, von der Präsentationsschicht von Rechner A gemäß einem Standardformat „formatiert“, bevor sie über das Netzwerk gesendet werden. Sobald sie die Präsentationsschicht des Zielrechners B erreichen, der sie dank ihres Standardformats erkennt, werden sie anders formatiert, damit die Anwendung auf Rechner B sie erkennen kann. | |
Auf dieser Ebene finden wir Anwendungen, die im Allgemeinen nah am Benutzer angesiedelt sind, wie E-Mail oder Dateiübertragung. |
2.7.2. Das TCP/IP-Modell
Das OSI-Modell ist ein Idealmodell. Die TCP/IP-Protokollsuite nähert sich diesem auf folgende Weise an:
 |
- Die Netzwerkschnittstelle (die Netzwerkkarte des Computers) übernimmt die Funktionen der Schichten 1 und 2 des OSI-Modells
- die IP-Schicht (Internet Protocol) übernimmt die Funktionen der Schicht 3 (Netzwerk)
- Die TCP- (Transmission Control Protocol) oder UDP- (User Datagram Protocol) Schicht übernimmt die Funktionen von Schicht 4 (Transport). Das TCP-Protokoll stellt sicher, dass die zwischen den Rechnern ausgetauschten Datenpakete ihr Ziel erreichen. Ist dies nicht der Fall, sendet es die verlorenen Pakete erneut. Das UDP-Protokoll übernimmt diese Aufgabe nicht, sodass es dem Anwendungsentwickler obliegt, dies zu tun. Aus diesem Grund ist im Internet – das kein zu 100 % zuverlässiges Netzwerk ist – das TCP-Protokoll am weitesten verbreitet. Man spricht dabei von einem TCP-IP-Netzwerk.
- Die Anwendungsschicht umfasst die Funktionen der Schichten 5 bis 7 des OSI-Modells.
Webanwendungen befinden sich in der Anwendungsschicht und stützen sich daher auf TCP/IP-Protokolle. Die Anwendungsschichten von Client- und Server-Rechnern tauschen Nachrichten aus, die an die Schichten 1 bis 4 des Modells weitergeleitet werden, um an ihren Bestimmungsort geleitet zu werden. Um miteinander zu kommunizieren, müssen die Anwendungsschichten beider Rechner dieselbe Sprache oder dasselbe Protokoll „sprechen“. Das von Webanwendungen verwendete Protokoll heißt HTTP (HyperText Transfer Protocol). Es handelt sich um ein textbasiertes Protokoll, was bedeutet, dass die Rechner zur Kommunikation Textzeilen über das Netzwerk austauschen. Dieser Austausch ist standardisiert, d. h., der Client verfügt über eine Reihe von Nachrichten, um dem Server genau mitzuteilen, was er möchte, und der Server verfügt ebenfalls über eine Reihe von Nachrichten, um dem Client seine Antwort zu übermitteln. Dieser Nachrichtenaustausch erfolgt in folgender Form:
 |
Client --> Server
Wenn der Client eine Anfrage an den Webserver sendet, sendet er
- Textzeilen im HTTP-Format, um anzugeben, was er möchte
- eine Leerzeile
- optional ein Dokument
Server --> Client
Wenn der Server dem Client antwortet, sendet er
- Zeilen Text im HTTP-Format, um anzugeben, was er sendet
- eine Leerzeile
- optional ein Dokument
Die Kommunikation folgt daher in beide Richtungen demselben Format. In beiden Fällen kann ein Dokument gesendet werden, auch wenn es selten vorkommt, dass ein Client ein Dokument an den Server sendet. Das HTTP-Protokoll lässt dies jedoch zu. Dies ermöglicht es beispielsweise Abonnenten eines Internetdienstanbieters, verschiedene Dokumente auf ihre persönliche Website hochzuladen, die von diesem Anbieter gehostet wird. Die ausgetauschten Dokumente können beliebigen Typs sein. Stellen Sie sich einen Browser vor, der eine Webseite mit Bildern anfordert:
- Der Browser verbindet sich mit dem Webserver und fordert die gewünschte Seite an. Die angeforderten Ressourcen werden durch URLs (Uniform Resource Locators) eindeutig identifiziert. Der Browser sendet nur HTTP-Header und kein Dokument.
- Der Server antwortet. Er sendet zunächst HTTP-Header, die angeben, um welche Art von Antwort es sich handelt. Dies kann ein Fehler sein, wenn die angeforderte Seite nicht existiert. Wenn die Seite existiert, gibt der Server in den HTTP-Headern seiner Antwort an, dass er im Anschluss daran ein HTML-Dokument (HyperText Markup Language) senden wird. Dieses Dokument besteht aus einer Folge von Textzeilen im HTML-Format. HTML-Text enthält Tags (Markierungen), die dem Browser Anweisungen zur Darstellung des Textes geben.
- Der Client erkennt 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 Bilder sind nicht im HTML-Dokument 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, außer dass die angeforderte Ressource eine andere ist. Der Server bearbeitet diese Anfrage, indem er das angeforderte Bild an den Client sendet. Diesmal geben die HTTP-Header in der Antwort an, dass es sich bei dem gesendeten Dokument um ein Bild und nicht um ein HTML-Dokument handelt.
- Der Client ruft das gesendete Bild ab. Die Schritte 3 und 4 werden wiederholt, bis der Client (in der Regel ein Browser) über alle Dokumente verfügt, die zur Anzeige der gesamten Seite erforderlich sind.
2.7.3. Das HTTP-Protokoll
Lassen Sie uns das HTTP-Protokoll anhand von Beispielen näher betrachten. Was tauschen ein Browser und ein Webserver aus?
2.7.3.1. Die Antwort eines HTTP-Servers
Hier werden wir untersuchen, wie ein Webserver auf Anfragen seiner Clients reagiert. Der Webdienst oder HTTP-Dienst ist ein TCP/IP-Dienst, der typischerweise auf Port 80 läuft. Er könnte auch auf einem anderen Port laufen. In diesem Fall müsste der Client-Browser diesen Port in der angeforderten URL angeben. Eine URL hat im Allgemeinen dieses Format:
wobei
protokoll | http für den Webdienst. Ein Browser kann auch als Client für FTP, News, Telnet und andere Dienste fungieren. |
Rechner | Name des Rechners, auf dem der Webdienst gehostet wird |
Port | Webdienst-Port. Wenn es sich um 80 handelt, kann die Portnummer weggelassen werden. Dies ist der häufigste Fall |
Pfad | Pfad zur angeforderten Ressource |
info | zusätzliche Informationen, die dem Server zur Spezifizierung der Client-Anfrage bereitgestellt werden |
Was macht ein Browser, wenn ein Benutzer das Laden einer URL anfordert?
- Er baut eine TCP/IP-Verbindung zu dem Rechner und Port auf, die im Teil „Rechner[:Port]“ der URL angegeben sind. Der Aufbau einer TCP/IP-Verbindung bedeutet, dass ein „Kanal“ für die Kommunikation zwischen zwei Rechnern geschaffen wird. Sobald dieser Kanal aufgebaut ist, werden alle zwischen den beiden Rechnern ausgetauschten Informationen über ihn übertragen. Die Einrichtung dieser TCP/IP-Verbindung erfolgt noch ohne das HTTP-Protokoll des Webs.
- Sobald die TCP-IP-Verbindung hergestellt ist, sendet der Client seine Anfrage an den Webserver, indem er Textzeilen (Befehle) im HTTP-Format übermittelt. Er sendet den Teil „path/info“ der URL an den Server
- Der Server antwortet auf die gleiche Weise und über dieselbe Verbindung
- Eine der beiden Parteien entscheidet, die Verbindung zu schließen. Dies hängt vom verwendeten HTTP-Protokoll ab. Bei 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 einer Webseite abzurufen, für jede Anfrage eine neue Verbindung zu öffnen, was mit Kosten verbunden ist. Beim HTTP/1.1-Protokoll kann der Client den Server anweisen, die Verbindung offen zu halten, bis er den Server 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 erhalten wurde. Der Server erkennt diese Schließung und schließt die Verbindung ebenfalls.
Um den Datenaustausch zwischen einem Client und einem Webserver zu untersuchen, verwenden wir einen generischen TCP-Client. Dabei handelt es sich um ein Programm, das als Client für jeden Dienst fungieren kann, der ein textbasiertes Kommunikationsprotokoll wie das HTTP-Protokoll verwendet. Diese Textzeilen werden vom Benutzer über die Tastatur eingegeben. Dies setzt voraus, dass der Benutzer das Kommunikationsprotokoll des Dienstes kennt, auf den er zugreifen möchte. Die Antwort des Servers wird dann auf dem Bildschirm angezeigt. Das Programm wurde in Java geschrieben und ist im Anhang zu finden. Hier verwenden wir es in einem DOS-Fenster unter Windows und rufen es wie folgt auf:
mit
Maschinenname | Maschinenname der Maschine, auf der der zu kontaktierende Dienst läuft |
Port | Port, über den der Dienst bereitgestellt wird |
Mit diesen beiden Informationen baut das Programm eine TCP/IP-Verbindung zu dem angegebenen Rechner und Port auf. Diese Verbindung wird genutzt, um Textzeilen zwischen dem Client und dem Webserver auszutauschen. Die Zeilen des Clients werden vom Benutzer über die Tastatur eingegeben und an den Server gesendet. Die vom Server als Antwort zurückgegebenen Textzeilen werden auf dem Bildschirm angezeigt. So kann ein Dialog direkt zwischen dem Benutzer an der Tastatur und dem Webserver stattfinden. Probieren wir dies anhand der bereits vorgestellten Beispiele aus. Wir hatten die folgende statische HTML-Seite 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:
Wir sehen, dass die angeforderte URL lautet: http://localhost:81/essais/essai1.html. Der Webserver läuft also auf localhost (dem lokalen Rechner) auf Port 81. Wenn wir den HTML-Quellcode dieser Webseite anzeigen (Ansicht/Quelltext), sehen wir den ursprünglich erstellten HTML-Text:
Verwenden wir nun unseren generischen TCP-Client, um dieselbe URL abzufragen:
Dos>java clientTCPgenerique localhost 81
Commandes :
GET /essais/essai1.html HTTP/1.0
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 08:07:46 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Connection: close
<-- Content-Type: text/html
<--
<-- <html>
<-- <head>
<-- <title>essai 1 : une page statique</title>
<-- </head>
<-- <body>
<-- <center>
<-- <h1>Une page statique...</h1>
<-- </body>
<-- </html>
Wenn der Client mit dem Befehl java clientTCPgenerique localhost 81 gestartet wird, wird eine Verbindung zwischen dem Programm und dem Webserver hergestellt, der auf demselben Rechner (localhost) auf Port 81 läuft. Die Client-Server-Kommunikation im HTTP-Format kann nun beginnen. Zur Erinnerung: Diese Anfragen bestehen aus drei Komponenten:
- HTTP-Header
- Leerzeile
- optionale Daten
In unserem Beispiel sendet der Client nur eine Anfrage:
GET /tests/test1.html HTTP/1.0
Diese Zeile besteht aus drei Komponenten:
HTTP-Befehl zum Anfordern einer Ressource. Es gibt noch weitere: HEAD fordert eine Ressource an, beschränkt sich jedoch auf die HTTP-Header in der Antwort des Servers. Die Ressource selbst wird nicht gesendet. PUT ermöglicht es dem Client, ein Dokument an den Server zu senden | |
Angeforderte Ressource | |
Verwendete HTTP-Protokollversion. Hier 1.0. Das bedeutet, dass der Server die Verbindung schließt, sobald er seine Antwort gesendet hat |
Auf HTTP-Header muss immer eine Leerzeile folgen. Dies hat der Client hier getan. So weiß der Client oder Server, dass der HTTP-Teil des Austauschs abgeschlossen ist. Hier ist der Client fertig. Er hat kein Dokument mehr zu senden. Die Antwort des Servers beginnt dann und besteht in unserem Beispiel aus allen Zeilen, die mit dem Symbol <-- beginnen. Er sendet zunächst eine Reihe von HTTP-Headern, gefolgt von einer Leerzeile:
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 08:07:46 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Connection: close
<-- Content-Type: text/html
<--
Der Server gibt an
| |
Datum und Uhrzeit der Antwort | |
Der Server identifiziert sich. Hier handelt es sich um einen Apache-Server | |
Datum der letzten Änderung der vom Client angeforderten Ressource | |
... | |
Maßeinheit für die gesendeten Daten. Hier ist das Byte | |
Anzahl der Bytes im Dokument, die nach den HTTP-Headern gesendet werden sollen. Diese Zahl entspricht tatsächlich der Größe der Datei essai1.html in Bytes: | |
Der Server gibt an, dass er die Verbindung schließt, sobald das Dokument gesendet wurde | |
Der Server gibt an, dass er Text im HTML-Format senden wird. |
Der Client empfängt diese HTTP-Header und weiß nun, dass er 161 Bytes erhalten wird, die ein HTML-Dokument darstellen. Der Server sendet diese 161 Bytes unmittelbar nach der Leerzeile, die das Ende der HTTP-Header signalisiert hat:
<-- <html>
<-- <head>
<-- <title>essai 1 : une page statique</title>
<-- </head>
<-- <body>
<-- <center>
<-- <h1>Une page statique...</h1>
<-- </body>
<-- </html>
Hier erkennen wir die ursprünglich erstellte HTML-Datei. Wäre unser Client ein Browser, würde er diese Textzeilen nach dem Empfang so interpretieren, dass dem Benutzer die folgende Seite angezeigt wird:
Verwenden wir erneut unseren generischen TCP-Client, um dieselbe Ressource anzufordern, diesmal jedoch mit dem HEAD-Befehl, der nur die Antwort-Header anfordert:
Dos>java.bat clientTCPgenerique localhost 81
Commandes :
HEAD /essais/essai1.html HTTP/1.1
Host: localhost:81
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 09:07:25 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Content-Type: text/html
<--
Wir erhalten das gleiche Ergebnis wie zuvor, ohne das HTML-Dokument. Beachten Sie, dass der Client in seiner HEAD-Anfrage angegeben hat, dass er HTTP-Version 1.1 verwendet. Dies erfordert, dass er einen zweiten HTTP-Header sendet, der das Paar aus Rechner und Port angibt, das der Client abfragen möchte: Host: localhost:81.
Nun wollen wir ein Bild sowohl über einen Browser als auch über den generischen TCP-Client anfordern. Zunächst über einen Browser:
Die Datei univ01.gif ist 3167 Byte groß:
Verwenden wir nun den generischen TCP-Client:
E:\data\serge\JAVA\SOCKETS\client générique>java clientTCPgenerique localhost 81
Commandes :
HEAD /images/univ01.gif HTTP/1.1
host: localhost:81
<-- HTTP/1.1 200 OK
<-- Date: Tue, 09 Jul 2002 13:53:24 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Fri, 14 Apr 2000 11:37:42 GMT
<-- ETag: "0-c5f-38f70306"
<-- Accept-Ranges: bytes
<-- Content-Length: 3167
<-- Content-Type: image/gif
<--
Beachten Sie die folgenden Punkte in der Antwort des Servers:
| |
| |
|
2.7.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? Wir haben bereits in den vorherigen Beispielen begonnen, diese Frage zu beantworten. Wir sind auf drei Befehle gestoßen:
| |
| |
|
Es gibt noch weitere Befehle. Um diese zu erkunden, verwenden wir nun einen generischen TCP-Server. Dabei handelt es sich um ein in Java geschriebenes Programm, das Sie ebenfalls im Anhang finden. Es wird mit dem Befehl java genericTCPserver listeningPort gestartet, wobei listeningPort der Port ist, mit dem sich Clients verbinden müssen. Das Programm genericTCPserver
- zeigt auf dem Bildschirm die von Clients gesendeten Befehle an
- und sendet ihnen als Antwort die Textzeilen, die ein Benutzer über die Tastatur eingibt. Der Benutzer fungiert somit als Server. In unserem Beispiel übernimmt der Benutzer an der Tastatur die Rolle eines Webdienstes.
Simulieren wir nun einen Webserver, indem wir unseren generischen Server auf Port 88 starten:
Dos> java serveurTCPgenerique 88
Serveur générique lancé sur le port 88
Öffnen wir nun einen Browser und rufen wir die URL http://localhost:88/exemple.html auf. Der Browser stellt daraufhin eine Verbindung zu Port 88 auf dem lokalen Rechner her und fordert die Seite /example.html an:
Werfen wir nun einen Blick auf unser Serverfenster, das anzeigt, was der Client gesendet hat (einige Zeilen, die sich speziell auf den Betrieb des Programms serveurTCPgenerique beziehen, wurden der Einfachheit halber weggelassen):
Dos>java serveurTCPgenerique 88
Serveur générique lancé sur le port 88
...
<-- GET /exemple.html HTTP/1.1
<-- Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */*
<-- Accept-Language: fr
<-- Accept-Encoding: gzip, deflate
<-- User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705; .NET CLR 1.0.2 914)
<-- Host: localhost:88
<-- Connection: Keep-Alive
<--
Die Zeilen, denen das Symbol <-- vorangestellt ist, wurden vom Client gesendet. Darin sind HTTP-Header enthalten, die wir bisher noch nicht gesehen haben:
| |
| |
| |
| |
|
Die vom Browser gesendeten HTTP-Header enden erwartungsgemäß mit einer Leerzeile.
Erstellen wir eine Antwort für unseren Client. Der Benutzer am Bildschirm ist hier der eigentliche Server und kann die Antwort manuell erstellen. Erinnern Sie sich an die Antwort, die ein Webserver in einem früheren Beispiel gesendet hat:
<-- HTTP/1.1 200 OK
<-- Date: Mon, 08 Jul 2002 08:07:46 GMT
<-- Server: Apache/1.3.24 (Win32) PHP/4.2.0
<-- Last-Modified: Mon, 08 Jul 2002 08:00:30 GMT
<-- ETag: "0-a1-3d29469e"
<-- Accept-Ranges: bytes
<-- Content-Length: 161
<-- Connection: close
<-- Content-Type: text/html
<--
<-- <html>
<-- <head>
<-- <title>essai 1 : une page statique</title>
<-- </head>
<-- <body>
<-- <center>
<-- <h1>Une page statique...</h1>
<-- </body>
<-- </html>
Versuchen wir, manuell (über die Tastatur) eine ähnliche Antwort zu erstellen. Zeilen, die mit --> : beginnen, werden an den Client gesendet:
...
<-- Host: localhost:88
<-- Connection: Keep-Alive
<--
--> : HTTP/1.1 200 OK
--> : Server: serveur tcp generique
--> : Connection: close
--> : Content-Type: text/html
--> :
--> : <html>
--> : <head><title>Serveur generique</title></head>
--> : <body>
--> : <center>
--> : <h2>Reponse du serveur generique</h2>
--> : </center>
--> : </body>
--> : </html>
fin
Der Befehl „end“ ist spezifisch für den Betrieb des Programms „serverTCPgenerique“. Er beendet die Ausführung des Programms und schließt die Verbindung zwischen Server und Client. In unserer Antwort haben wir uns auf die folgenden HTTP-Header beschränkt:
HTTP/1.1 200 OK
--> : Server: serveur tcp generique
--> : Connection: close
--> : Content-Type: text/html
--> :
Wir geben die Größe der zu sendenden Datei (Content-Length) nicht an, sondern weisen lediglich darauf hin, dass wir die Verbindung (Connection: close) nach dem Senden schließen werden. Dies reicht für den Browser aus. Sobald er sieht, dass die Verbindung geschlossen wurde, weiß er, dass die Antwort des Servers vollständig ist, und zeigt die ihm gesendete HTML-Seite an. Die Seite sieht wie folgt aus:
--> : <html>
--> : <head><title>Serveur generique</title></head>
--> : <body>
--> : <center>
--> : <h2>Reponse du serveur generique</h2>
--> : </center>
--> : </body>
--> : </html>
Der Browser zeigt dann die folgende Seite an:
Wenn Sie oben auf „Ansicht/Quelltext“ klicken, um zu sehen, was der Browser empfangen hat, erhalten Sie:
Das heißt, genau das, was vom generischen Server gesendet wurde.
2.8. HTML
Ein Webbrowser kann verschiedene Dokumente anzeigen, wobei HTML-Dokumente (HyperText Markup Language) am häufigsten vorkommen. Diese bestehen aus Text, der mit Tags in der Form <tag>text</tag> formatiert ist. So wird der Text <B>important</B> als „important“ in Fettdruck angezeigt. Es gibt eigenständige Tags wie das <hr>-Tag, das eine horizontale Linie anzeigt. Wir werden nicht alle Tags behandeln, die in HTML-Text vorkommen können. Es gibt viele WYSIWYG-Programme, mit denen Sie eine Webseite erstellen können, ohne eine einzige Zeile HTML-Code schreiben zu müssen. Diese Tools generieren automatisch den HTML-Code für ein Layout, das mit der Maus und vordefinierten Steuerelementen erstellt wurde. Sie können also (mit der Maus) eine Tabelle in die Seite einfügen und dann den von der Software generierten HTML-Code anzeigen, um die Tags zu entdecken, die zur Definition einer Tabelle auf einer Webseite verwendet werden. So einfach ist das. Darüber hinaus sind HTML-Kenntnisse unerlässlich, da dynamische Webanwendungen den HTML-Code selbst generieren müssen, um ihn an Web-Clients zu senden. Dieser Code wird programmgesteuert generiert, und Sie müssen natürlich wissen, was zu generieren ist, damit der Client die gewünschte Webseite erhält.
Zusammenfassend lässt sich sagen, dass Sie nicht die gesamte HTML-Sprache beherrschen müssen, um mit der Webprogrammierung zu beginnen. Dieses Wissen ist jedoch notwendig und kann durch die Verwendung von WYSIWYG-Webseiten-Editoren wie Word, FrontPage, DreamWeaver und Dutzenden anderen erworben werden. Eine weitere Möglichkeit, die Feinheiten von HTML zu entdecken, besteht darin, im Web zu surfen und den Quellcode von Seiten anzusehen, die interessante Elemente enthalten, denen Sie zuvor noch nicht begegnet sind.
2.8.1. Ein Beispiel
Betrachten Sie das folgende Beispiel, das mit FrontPage Express erstellt wurde, einem kostenlosen Tool, das im Internet Explorer enthalten ist. Der von FrontPage generierte Code wurde hier vereinfacht. Dieses Beispiel enthält einige Elemente, die häufig in einem Webdokument vorkommen, wie zum Beispiel:
- eine Tabelle
- ein Bild
- einem Link
Ein HTML-Dokument hat im Allgemeinen folgende Form:
Das gesamte Dokument ist von den Tags <html>...</html> umschlossen. Es besteht aus zwei Teilen:
- <head>...</head>: Dies ist der nicht angezeigte Teil des Dokuments. Er liefert Informationen an den Browser, der das Dokument anzeigt. Er enthält häufig das Tag <title>...</title>, das den Text angibt, der in der Titelleiste des Browsers erscheint. Er kann auch andere Tags enthalten, darunter solche, die die Schlüsselwörter des Dokuments definieren, die dann von Suchmaschinen verwendet werden. Dieser Abschnitt kann auch Skripte enthalten, die in der Regel in JavaScript oder VBScript geschrieben sind und vom Browser ausgeführt werden.
- <body attributes>...</body>: Dies ist der Abschnitt, der vom Browser angezeigt wird. Die in diesem Abschnitt enthaltenen HTML-Tags teilen dem Browser das „gewünschte“ visuelle Layout des Dokuments mit. Jeder Browser interpretiert diese Tags auf seine eigene Weise. Daher kann es vorkommen, dass zwei Browser dasselbe Webdokument unterschiedlich darstellen. Dies ist im Allgemeinen eine der Herausforderungen, denen sich Webdesigner stellen müssen.
Der HTML-Code für unser Beispieldokument 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 nur die für uns relevanten Stellen hervorgehoben:
HTML | Tags und HTML-Beispiele |
<title>Tags</title> Tags werden in der Titelleiste des Browsers angezeigt, wenn das Dokument angezeigt wird | |
<hr>: zeigt eine horizontale Linie an | |
<table attributes>....</table>: zur Definition der Tabelle <tr attributes>...</tr>: zum Definieren einer Zeile <td attributes>...</td>: zum Definieren einer Zelle Beispiele: <table border="1">...</table>: Das Attribut „border“ definiert die Dicke des Tabellenrandes <td valign="middle" align="center" width="150">cell(1,2)</td>: definiert eine Zelle, deren Inhalt cell(1,2) ist. 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"), 95 Pixel hoch (height="95"), 80 Pixel breit (width="80") und dessen Quelldatei sich auf dem Webserver unter /images/univ01.gif befindet (src="/images/univ01.gif"). Dieser Link befindet sich in einem Webdokument, auf das über die URL http://localhost:81/html/balises.htm zugegriffen wird. Daher fordert der Browser die URL http://localhost:81/images/univ01.gif an, um das hier referenzierte Bild abzurufen. | |
<a href="http://istia.univ-angers.fr">here</a>: macht den Text „here“ zu einem Link zur URL http://istia.univ-angers.fr. | |
<body background="/images/standard.jpg">: gibt an, dass sich das Bild, das als Seitenhintergrund verwendet werden soll, unter der URL /images/standard.jpg auf dem Webserver befindet. In unserem Beispiel fordert der Browser die URL http://localhost:81/images/standard.jpg an, um dieses Hintergrundbild abzurufen. |
An diesem einfachen Beispiel sehen wir, dass der Browser zum Erstellen des gesamten Dokuments drei Anfragen an den Server senden muss:
- http://localhost:81/html/balises.htm, um den HTML-Quellcode 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 ebenfalls mit FrontPage erstelltes Webformular.
Der von FrontPage generierte und leicht bereinigte HTML-Code lautet wie folgt:
<html>
<head>
<title>balises</title>
<script language="JavaScript">
function effacer(){
alert("Vous avez cliqué sur le bouton Effacer");
}//effacer
</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 Zuordnung zwischen <--> und dem HTML-Tag lautet wie folgt:
Visuell | HTML-Tag |
<form method="POST" > | |
<input type="text" name="txtInput" size="20" value="ein paar Worte"> | |
<input type="password" name="txtPassword" size="20" value="aPassword"> | |
<textarea rows="2" name="inputArea" cols="20"> Zeile 1 Zeile 2 Zeile 3 </textarea> | |
<input type="radio" value="Ja" name="R1">Ja <input type="radio" name="R1" value="No" checked>Nein | |
<input type="checkbox" name="C1" value="one">1 <input type="checkbox" name="C2" value="zwei" checked>2 <input type="checkbox" name="C3" value="three">3 | |
<select size="1" name="cmbValues"> <option>Option1</option> <option selected>Option 2</option> <option>Option3</option> </select> | |
<select size="3" name="lst1"> <option selected>Liste1</option> <option>Liste2</option> <option>Liste3</option> <option>list4</option> <option>Liste5</option> </select> | |
<select size="3" name="lst2" multiple> <option>Liste1</option> <option>Liste2</option> <option selected>list3</option> <option>Liste4</option> <option>Liste5</option> </select> | |
<input type="submit" value="Absenden" name="cmdSubmit"> | |
<input type="reset" value="Zurücksetzen" name="cmdReset"> | |
<input type="button" value="Löschen" name="cmdClear" onclick="clear()"> |
Sehen wir uns diese verschiedenen Steuerelemente einmal an.
2.8.1.1. Die
<form method="POST" > |
<form name="..." method="..." action="...">...</form> | |
name="exampleform": Formularname method="..." : Methode, die der Browser verwendet, um die im Formular gesammelten Werte an den Webserver zu senden action="..." : URL, an die die im Formular gesammelten 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 innerhalb eines Formulars. Dieser Name ist nützlich, wenn das Webdokument Skripte enthält, die auf Formularelemente verweisen müssen. Der Zweck eines Formulars besteht darin, vom Benutzer über Tastatur oder Maus eingegebene Informationen zu erfassen und an eine Webserver-URL zu senden. An welche? An diejenige, auf die im Attribut action="URL" verwiesen wird. Fehlt dieses Attribut, werden die Informationen an die URL 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 „Anforderer“ von Informationen von einem Webserver betrachtet, niemals als „Lieferanten“ von Informationen an diesen. Wie liefert ein Web-Client Informationen (die im Formular enthaltenen Daten) an einen Webserver? Wir werden später noch ausführlich darauf zurückkommen. Er kann zwei verschiedene Methoden verwenden, die als POST und GET bezeichnet werden. Das Attribut method="method" des Tags <form>, wobei method entweder GET oder POST ist, teilt dem Browser mit, welche Methode er verwenden soll, um die im Formular gesammelten Informationen an die durch das Attribut action="URL" angegebene URL zu senden. Wenn das Attribut method nicht angegeben ist, wird standardmäßig die GET-Methode verwendet. |
2.8.1.2. Eingabefeld
<input type="text" name="txtInput" size="20" value="einige Wörter"> <input type="password" name="txtMdp" size="20" value="aPassword"> |
<input type="..." name="..." size=".." value=".."> Das `input`-Tag steht für verschiedene Steuerelemente zur Verfügung. Das `type`-Attribut dient dazu, zwischen diesen verschiedenen Steuerelementen zu unterscheiden. | |
type="text": gibt an, dass es sich um ein Texteingabefeld handelt type="password": Die Zeichen im Eingabefeld werden durch Sternchen (*) ersetzt. Dies ist der einzige Unterschied zu einem normalen Eingabefeld. Diese Art von Steuerelement eignet sich zur Eingabe von Passwörtern. size="20": Anzahl der im Feld sichtbaren Zeichen – verhindert nicht die Eingabe weiterer Zeichen name="txtInput": Name des Steuerelements value="some words": Text, der im Eingabefeld angezeigt wird. |
2.8.1.3. Mehrzeiliges Eingabefeld
<textarea rows="2" name="areaSaisie" cols="20"> Zeile 1 Zeile 2 Zeile 3 </textarea> |
<textarea ...>text</textarea> zeigt ein mehrzeiliges Texteingabefeld an, in dem bereits Text steht | |
rows="2": Anzahl der Zeilen cols="'20" : Anzahl der Spalten name="areaSaisie": Name des Steuerelements |
2.8.1.4. Optionsfelder
<input type="radio" value="Ja" name="R1">Ja <input type="radio" name="R1" value="no" checked>Nein |
<input type="radio" attribute2="value2" ....>text Zeigt ein Optionsfeld mit Text daneben an. | |
name="radio": Name des Steuerelements. Optionsfelder mit demselben Namen bilden eine Gruppe sich gegenseitig ausschließender Schaltflächen: Es kann nur eines davon ausgewählt werden. value="value": dem Optionsfeld zugewiesener Wert. Verwechsle diesen Wert nicht mit dem Text, der neben dem Optionsfeld angezeigt wird. Der Text dient nur zu Anzeigezwecken. checked: Wenn dieses Schlüsselwort vorhanden ist, ist das Optionsfeld aktiviert; andernfalls ist es nicht aktiviert. |
2.8.1.5. Kontrollkästchen
<input type="checkbox" name="C1" value="one">1 <input type="checkbox" name="C2" value="two" checked>2 <input type="checkbox" name="C3" value="three">3 |
<input type="checkbox" attribute2="value2" ....>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="value": dem Kontrollkästchen zugewiesener Wert. Verwechsle diesen Wert nicht mit dem Text, der neben dem Kontrollkästchen angezeigt wird. Der Text dient nur zu Anzeigezwecken. checked: Wenn dieses Schlüsselwort vorhanden ist, ist das Optionsfeld aktiviert; andernfalls ist es nicht aktiviert. |
2.8.1.6. Dropdown-Liste (Kombinationsfeld)
<select size="1" name="cmbValues"> <option>Auswahl1</option> <option selected>Option2</option> <option>Option3</option> </select> |
<select size=".." name=".."> <Option [ausgewählt]>...</option> ... </select> zeigt den Text zwischen den Tags <option>...</option> in einer Liste an | |
name="cmbValeurs": Name des Steuerelements. size="1": Anzahl der sichtbaren Listenelemente. Mit size="1" funktioniert die Liste wie ein Kombinationsfeld. selected: Wenn dieses Schlüsselwort für ein Listenelement vorhanden ist, wird dieses Element in der Liste als ausgewählt angezeigt. In unserem obigen Beispiel erscheint das Listenelement choice2 bei der ersten Anzeige als ausgewähltes Element in der Kombinationsfeld. |
2.8.1.7. Liste mit Einzelauswahl
<select size="3" name="lst1"> <option selected>Liste1</option> <option>Liste2</option> <option>Liste3</option> <option>list4</option> <option>Liste5</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> zeigt den Text zwischen den Tags <option>...</option> in einer Liste an | |
wie bei der Dropdown-Liste, die nur einen Eintrag anzeigt. Dieses Steuerelement unterscheidet sich von der vorherigen Dropdown-Liste lediglich durch das Attribut size>1. |
2.8.1.8. Mehrfachauswahlliste
<select size="3" name="lst2" multiple> <option selected>list1</option> <option>Liste2</option> <option selected>Liste3</option> <option>list4</option> <option>list5</option> </select> |
<select size=".." name=".." multiple> <option [selected]>...</option> ... </select> zeigt den Text zwischen den Tags <option>...</option> in einer Liste an | |
multiple: Ermöglicht die Auswahl mehrerer Elemente aus der Liste. Im obigen Beispiel sind die Elemente list1 und list3 beide ausgewählt. |
2.8.1.9. Schaltfläche
<input type="button" value="Löschen" name="cmdClear" onclick="clear()"> |
<input type="button" value="..." name="..." onclick="clear()" ....> | |
type="button": definiert ein Schaltflächen-Steuerelement. Es gibt zwei weitere Arten von Schaltflächen: submit und reset. value="Clear": Der auf der Schaltfläche angezeigte Text onclick="function()": ermöglicht es Ihnen, eine Funktion zu definieren, die ausgeführt wird, wenn der Benutzer auf die Schaltfläche klickt. Diese Funktion ist Teil der Skripte, die im angezeigten Webdokument definiert sind. Die obige Syntax ist JavaScript-Syntax. Wenn die Skripte in VBScript geschrieben sind, würden Sie onclick="function" ohne die Klammern schreiben. Die Syntax bleibt gleich, wenn Parameter an die Funktion übergeben werden müssen: onclick="function(val1, val2,...)" In unserem Beispiel ruft ein Klick auf die Schaltfläche „Clear“ die folgende JavaScript-Funktion „clear“ auf: Die Funktion „clear“ zeigt eine Meldung an:  |
2.8.1.10. Senden-Schaltfläche
<input type="submit" value="Senden" name="cmdSend"> |
<input type="submit" value="Senden" name="cmdRenvoyer"> | |
type="submit": Definiert die Schaltfläche als Schaltfläche zum Senden von 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> definierte URL unter Verwendung der im Attribut „method“ desselben Tags definierten Methode. value="Senden": Der auf der Schaltfläche angezeigte Text |
2.8.1.11. Schaltfläche „Zurücksetzen“
<input type="reset" value="Zurücksetzen" name="cmdReset"> |
<input type="reset" value="Zurücksetzen" name="cmdReset"> | |
type="reset": Definiert die Schaltfläche als Schaltfläche zum Zurücksetzen des Formulars. Wenn der Benutzer auf diese Schaltfläche klickt, stellt 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.8.1.12. Verstecktes Feld
<input type="hidden" name="secret" value="aValue"> |
<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 seinen Browser anweisen, den Quellcode anzuzeigen, würde er das Vorhandensein des Tags <input type="hidden" value="..."> und somit den Wert des versteckten Feldes sehen. value="aValue": Wert des versteckten Feldes. Was ist der Zweck eines versteckten Feldes? Es ermöglicht dem Webserver, Informationen über die Anfragen eines Clients hinweg zu speichern. Betrachten wir eine Online-Shopping-Anwendung. Der Kunde kauft auf der ersten Seite eines Katalogs einen ersten Artikel art1 in der Menge q1 und wechselt dann zu einer neuen Seite im Katalog. Um sich zu merken, dass der Kunde q1 Artikel von art1 gekauft hat, kann der Server diese beiden Informationen in ein verstecktes Feld im Webformular auf der neuen Seite einfügen. Auf dieser neuen Seite kauft der Client q2 Einheiten des Artikels art2. Wenn die Daten aus diesem zweiten Formular an den Server übermittelt werden, erhält der Server nicht nur die Information (q2,art2), sondern auch (q1,art1), die ebenfalls Teil des Formulars als verstecktes Feld ist, das vom Benutzer nicht geändert werden kann. Der Webserver fügt dann die Informationen (q1,art1) und (q2,art2) in ein neues verstecktes Feld ein und sendet eine neue Katalogseite. Und so weiter. |
2.8.2. Senden von Formularwerten an einen Webserver durch einen Webclient
Wir haben in der vorherigen Lektion 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 GET- und die POST-Methode. Schauen wir uns ein Beispiel an, um den Unterschied zwischen den beiden Methoden zu verdeutlichen. Wir greifen das vorherige Beispiel wieder auf und gehen wie folgt vor:
- Ein Browser fordert die URL des Beispiels von einem Webserver an
- Sobald das Formular geladen ist, füllen wir es aus
- Bevor wir die Formularwerte durch Klicken auf die Schaltfläche „Absenden“ an den Webserver senden, stoppen wir den Webserver und ersetzen ihn durch den zuvor verwendeten generischen TCP-Server. Erinnern Sie sich daran, dass dieser Server die Textzeilen, die ihm vom Webclient gesendet werden, auf dem Bildschirm anzeigt. Auf diese Weise sehen wir genau, was der Browser sendet.
Das Formular wird wie folgt ausgefüllt:
Die für dieses Dokument verwendete URL lautet wie folgt:
2.8.2.1. GET-Methode
Das HTML-Dokument ist so programmiert, dass der Browser die GET-Methode verwendet, um die Formularwerte an den Webserver zu senden. Wir haben daher Folgendes geschrieben:
Wir stoppen den Webserver und starten unseren generischen TCP-Server auf Port 81:
E:\data\serge\JAVA\SOCKETS\serveur générique>java serveurTCPgenerique 81
Serveur générique lancé sur le port 81
Kehren wir nun zu unserem Browser zurück, um die Formulardaten über die Schaltfläche „Senden“ an den Webserver zu senden:
Folgendes empfängt der generische TCP-Server:
<-- GET /html/balises.htm?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&area
Saisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&
cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
<-- Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd
.ms-powerpoint, application/vnd.ms-excel, */*
<-- Referer: http://localhost:81/html/balises.htm
<-- Accept-Language: fr
<-- Accept-Encoding: gzip, deflate
<-- User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)
<-- Host: localhost:81
<-- Connection: Keep-Alive
<--
Es steht alles im ersten vom Browser gesendeten HTTP-Header:
<-- GET /html/balises.htm?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&area
Saisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&
cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
Wir sehen, dass dies wesentlich komplexer ist als das, was wir bisher kennengelernt haben. Es verwendet die GET-URL-Syntax von HTTP/1.1, allerdings in einer speziellen Form: GET URL?param1=value1¶m2=value2&... HTTP/1.1, wobei die Parameter die Namen der Webformular-Steuerelemente und die Werte die ihnen zugeordneten Werte sind. Schauen wir uns das genauer an. Nachfolgend finden Sie eine dreispaltige Tabelle:
- Spalte 1: zeigt die Definition eines HTML-Steuerelements aus dem Beispiel
- Spalte 2: zeigt, wie dieses Steuerelement in einem Browser angezeigt wird
- Spalte 3: zeigt den Wert, den der Browser für das Steuerelement in Spalte 1 an den Server sendet, in der Form, wie er in der GET-Anfrage aus dem Beispiel vorkommt
HTML-Steuerelement | Visuell | zurückgegebene Werte |
<input type="radio" value="Yes" name="R1">Ja <input type="radio" name="R1" value="no" checked>Nein |  | – der Wert des value-Attributs des vom Benutzer ausgewählten Optionsfelds. |
<input type="checkbox" name="C1" value="one">1 <input type="checkbox" name="C2" value="two" checked>2 <input type="checkbox" name="C3" value="three">3 |  | C1=eins C2=zwei - Werte der value-Attribute der vom Benutzer ausgewählten Kontrollkästchen |
<input type="text" name="txtInput" size="20" value="ein paar Worte"> |  | txtInput=Web+Programmierung - vom Benutzer in das Eingabefeld eingegebener Text. Leerzeichen wurden durch das +-Zeichen ersetzt |
<input type="password" name="txtMdp" size="20" value="aPassword"> |  | txtPassword=thisIsSecret - vom Benutzer in das Eingabefeld eingegebener Text |
<textarea rows="2" name="inputArea" cols="20"> Zeile1 Zeile2 Zeile 3 </textarea> |  | inputField=die+Grundlagen+der+Web%0D%0A Webprogrammierung - vom Benutzer in das Eingabefeld eingegebener Text. %OD%OA ist das Zeichen für Zeilenende. Leerzeichen wurden durch das +-Zeichen ersetzt |
<select size="1" name="cmbValeurs"> <option>Auswahl1</option> <option selected>Auswahl2</option> <option>Auswahl3</option> </select> |  | cmbValues=dropdown3 - vom Benutzer aus der Einfachauswahlliste ausgewählter Wert |
<select size="3" name="lst1"> <option selected>list1</option> <option>list2</option> <option>list3</option> <option>list4</option> <option>Liste5</option> </select> |  | lst1=list3 - vom Benutzer aus der Einfachauswahlliste ausgewählter Wert |
<select size="3" name="lst2" multiple> <Option ausgewählt>Liste1</option> <option>list2</option> <option selected>Liste3</option> <option>Liste4</option> <option>Liste5</option> </select> |  | lst2=list1 lst2=list3 - vom Benutzer aus der Mehrfachauswahlliste ausgewählte Werte |
<input type="submit" value="Absenden" name="cmdSubmit"> | cmdSubmit=Absenden - Name und Wert des Attributs der Schaltfläche, die zum Senden der Formulardaten an den Server verwendet wird | |
<input type="hidden" name="secret" value="aValue"> | secret=aValue - value-Attribut des versteckten Feldes |
Machen wir dasselbe noch einmal, aber lassen wir diesmal den Webserver die Antwort generieren und schauen wir uns an, wie sie aussieht. Die vom Webserver zurückgegebene Seite sieht wie folgt aus:
Sie ist genau dieselbe wie die, die ursprünglich vor dem Ausfüllen des Formulars empfangen wurde. Um zu verstehen, warum das so ist, müssen wir uns noch einmal die URL ansehen, die der Browser anfordert, wenn der Benutzer auf die Schaltfläche „Absenden“ klickt:
<-- GET /html/balises.htm?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&area
Saisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&
cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
Die angeforderte URL lautet /html/tags.htm. Wir übergeben auch die Formularwerte an diese URL. Derzeit verwendet die URL /html/tags.htm, bei der es sich um eine statische Seite handelt, diese Werte nicht. Daher entspricht die vorstehende GET-Anfrage
und deshalb hat uns der Server die ursprüngliche Seite erneut gesendet. Beachten Sie, dass der Browser die vollständige angeforderte URL anzeigt:
2.8.2.2. POST-Methode
Das HTML-Dokument ist so programmiert, dass der Browser nun die POST-Methode verwendet, um die Formularwerte an den Webserver zu senden:
Wir stoppen den Webserver und starten den generischen TCP-Server (den wir bereits kennen, der aber für diesen Zweck leicht modifiziert wurde) auf Port 81:
E:\data\serge\JAVA\SOCKETS\serveur générique>java serveurTCPgenerique2 81
Serveur générique lancé sur le port 81
Nun kehren wir zu unserem Browser zurück, um die Formulardaten über die Schaltfläche „Senden“ an den Webserver zu senden:
Folgendes empfängt der generische TCP-Server:
<-- POST /html/balises.htm HTTP/1.1
<-- Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, application/vnd
.ms-powerpoint, application/vnd.ms-excel, */*
<-- Referer: http://localhost:81/html/balises.htm
<-- Accept-Language: fr
<-- Content-Type: application/x-www-form-urlencoded
<-- Accept-Encoding: gzip, deflate
<-- User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705)
<-- Host: localhost:81
<-- Content-Length: 210
<-- Connection: Keep-Alive
<-- Cache-Control: no-cache
<--
<-- 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
Im Vergleich zu dem, was wir bereits wissen, stellen wir folgende Änderungen in der Browseranfrage fest:
- Der anfängliche HTTP-Header lautet nicht mehr GET, sondern POST. Die Syntax lautet POST HTTP/1.1 URL, wobei URL die vom Browser angeforderte URL ist. Gleichzeitig bedeutet POST, dass der Browser Daten an den Server senden möchte.
- Der Header Content-Type: application/x-www-form-urlencoded gibt den Typ der Daten an, die der Browser senden wird. Diese Daten bestehen aus Formular-Daten (x-www-form), die URL-kodiert wurden. Diese Kodierung stellt sicher, dass bestimmte Zeichen in den übertragenen Daten umgewandelt werden, um zu verhindern, dass der Server sie falsch interpretiert. So wird das Leerzeichen durch + ersetzt, der Zeilenumbruch durch %OD%OA und so weiter. Im Allgemeinen werden alle Zeichen in den Daten, die vom Server falsch interpretiert werden könnten (&, +, %, usw.), in %XX umgewandelt, wobei XX für ihren Hexadezimalcode steht.
- Die Zeile Content-Length: 210 teilt dem Server mit, wie viele Zeichen der Client senden wird, sobald die HTTP-Header vollständig sind, d. h. nach der Leerzeile, die das Ende der Header signalisiert.
- Die Daten (210 Zeichen): R1=Yes&C1=one&C2=two&txtInput=web+programming&txtPassword=thisissecret&areaInput=the+basics+of+web%0D%0Aweb+programming&cmbValues=choice3&lst1=list3&lst2=list1&lst2=list3&cmdSubmit=Submit&secret=aValue
Beachten Sie, dass die per POST gesendeten Daten dasselbe Format haben wie die per GET gesendeten Daten.
Ist eine Methode besser als die andere? Wir haben gesehen, dass, wenn die Werte eines Formulars vom Browser mit der GET-Methode gesendet würden, der Browser die angeforderte URL in seiner Adressleiste in der Form URL?param1=val1¶m2=val2&.... anzeigen würde. Dies kann entweder als Vorteil oder als Nachteil angesehen werden:
- ein Vorteil, wenn Sie dem Benutzer ermöglichen möchten, diese parametrisierte URL in seinen Lesezeichen zu speichern
- ein Nachteil, wenn Sie nicht möchten, dass der Benutzer Zugriff auf bestimmte Formularinformationen hat, wie z. B. versteckte Felder
Von nun an werden wir in unseren Formularen fast ausschließlich die POST-Methode verwenden.
2.8.2.3. Werte aus einem Webformular abrufen
Eine statische Seite, die von einem Client angefordert wird, der auch Parameter über POST oder GET sendet, kann diese Parameter in keiner Weise abrufen. Nur ein Programm kann dies tun, und es ist das Programm, das dann eine Antwort an den Client generiert – eine Antwort, die dynamisch ist und im Allgemeinen auf den empfangenen Parametern basiert. Dies ist der Bereich der Webprogrammierung, ein Thema, das wir im nächsten Kapitel mit einer Einführung in Java-Webprogrammierungstechnologien – Servlets und JSP-Seiten – näher behandeln werden.