2. Die Grundlagen

In diesem Kapitel stellen wir die Grundlagen der Webprogrammierung vor. Das Hauptziel besteht darin, die Schlüsselprinzipien der Webprogrammierung vorzustellen, die unabhängig von der zur Umsetzung verwendeten Technologie sind. Es enthält zahlreiche Beispiele, die Sie ausprobieren sollten, um die Philosophie der Webentwicklung schrittweise zu „verinnerlichen“. Die zum Testen erforderlichen kostenlosen Tools sind am Ende des Dokuments im Anhang „Web-Tools“ aufgeführt.

2.1. Komponenten einer Webanwendung

Server

Client-Rechner15

Anzahl	Rolle	Häufige Beispiele
1	Server-Betriebssystem	Linux, Windows
2	Webserver	Apache (Linux, Windows) IIS (NT), PWS (Win9x), Cassini (Windows + .NET-Plattform)
3	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)
4	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)
5	Client-Betriebssystem	Linux, Windows
6	Webbrowser	Netscape, Internet Explorer, Mozilla, Opera
7	Clientseitige Skripte, die 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. Der Datenaustausch in einer Webanwendung mit einem Formular

ServerClient-Rechner

Nummer	Rolle
1	Der Browser fordert zum ersten Mal eine URL an (http://machine/url). Es werden keine Parameter übergeben.
2	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.
3	Der Benutzer übermittelt die Formulardaten, die dann an den Webserver gesendet werden. Der Browser lädt die ursprüngliche URL oder gegebenenfalls eine andere neu und sendet gleichzeitig die Formularwerte an den Server. Hierfür stehen zwei Methoden zur Verfügung: GET und POST. Nach Erhalt der Anfrage des Clients führt der Server das mit der angeforderten URL verknüpfte Skript (SA) aus, das die Parameter erkennt und verarbeitet.
4	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. Notationen

Im Folgenden gehen wir davon aus, dass eine Reihe von Tools installiert wurde, und verwenden die folgenden Notationen:

Notation	Bedeutung
<apache>	Stammverzeichnis des Apache-Serververzeichnisbaums
<apache-DocumentRoot>	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.
<apache-cgi-bin>	Stammverzeichnis der Verzeichnisstruktur, die mit dem Alias cgi-bin verknüpft ist und in der 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.
<IIS-DocumentRoot>	Das Stammverzeichnis für Webseiten, die von IIS, PWS oder Cassini bereitgestellt werden. Webseiten müssen sich unter diesem Stammverzeichnis befinden. Somit entspricht die URL http://localhost/page1.htm der Datei <IIS-DocumentRoot>\page1.htm.
<perl>	Stammverzeichnis der Perl-Sprachverzeichnisstruktur. Die ausführbare Datei perl.exe befindet sich normalerweise in <perl>\bin.
<php>	Stammverzeichnis der PHP-Verzeichnisstruktur. Die ausführbare Datei php.exe befindet sich normalerweise in <php>.
<java>	Stammverzeichnis der Java-Verzeichnisstruktur. Java-bezogene ausführbare Dateien befinden sich in <java>\bin.
<tomcat>	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

Informationen zur Installation dieser Tools finden Sie im Anhang.

2.4. 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. Wir werden zwei Webserver verwenden: Apache und IIS. IIS ist zwar ein kommerzielles Produkt, steht jedoch in zwei eingeschränkteren, aber kostenlosen Versionen zur Verfügung:

• PWS für Win9x-Rechner
• Cassini für Windows 2000- und XP-Rechner

Der Ordner <IIS-DocumentRoot> ist in der Regel der Ordner [Laufwerk:\inetpub\wwwroot], wobei [Laufwerk] das Laufwerk (C, D, ...) ist, auf dem IIS installiert wurde. Dasselbe gilt für PWS. Bei Cassini hängt der Ordner <IIS-DocumentRoot> davon ab, wie der Server gestartet wurde. Der Anhang zeigt, dass der Cassini-Server in einem DOS-Fenster (oder über eine Verknüpfung) wie folgt gestartet werden kann:

dos>webserver /port:N /path:"P" /vpath:"/V"

Die Anwendung [WebServer], auch bekannt als Cassini-Webserver, akzeptiert drei Parameter:

• /port: Portnummer des Webdienstes. Kann eine beliebige Zahl sein. Der Standardwert ist 80
• /path: physischer Pfad zu einem Ordner auf der Festplatte
• /vpath: virtueller Ordner, der dem vorangehenden physischen Ordner zugeordnet ist. Beachten Sie, dass die Syntax nicht /path=path lautet, sondern /vpath:path, entgegen der Angabe im obigen Hilfefenster.

Wenn Cassini wie folgt gestartet wird:

dos>webserver /port:N /path:"P" /vpath:"/"

dann ist der Ordner „P“ das Stammverzeichnis des Webverzeichnisbaums des Cassini-Servers. Dies ist somit der Ordner, der durch <IIS-DocumentRoot> bezeichnet wird. Im folgenden Beispiel gilt daher:

dos12>webserver /path:"d:\data\devel\webmatrix" /vpath:"/"

läuft der Cassini-Server auf Port 80, und das Stammverzeichnis seines <IIS-DocumentRoot>-Verzeichnisses 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 einzelne Datei repräsentiert, die mit einem beliebigen Texteditor erstellt werden kann. Es ist keine IDE erforderlich.

2.4.1. en zu statischen HTML-Seiten (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>

die folgende Webseite erzeugt:

Die Tests

Test1

• Starten Sie den Apache-Server
• Legen Sie das Skript test1.html in <apache-DocumentRoot> ab
• Rufen Sie die URL http://localhost/essai1.html in einem Browser auf
• Beenden Sie den Apache-Server

Test2

• Starten Sie den IIS/PWS/Cassini-Server
• Legen Sie das Skript test1.html in <IIS-DocumentRoot> ab
• Rufen Sie die URL http://localhost/essai1.html in einem Browser auf

2.4.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 IIS/PWS-Server
• Legen Sie das Skript essai2.asp in <IIS-DocumentRoot> ab
• Rufen Sie die URL http://localhost/essai2.asp mit einem Browser auf

2.4.3. Ein P- -ERL-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“. Gegebenenfalls müssen Sie diesen anpassen. Sobald das Skript von einem Webserver ausgeführt wird, erzeugt es die folgende Seite:

Der

• Webserver: Apache
• Schauen Sie zur Orientierung in die Konfigurationsdatei srm.conf oder httpd.conf (je nach Ihrer Apache-Version) im Verzeichnis <apache>\confs 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. 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 Speicher.

2.4.4. Ein PHP-Skript

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 vorherige Skript erzeugt die folgende Webseite:

Tests

Test1

• Überprüfen Sie die Konfigurationsdatei srm.conf oder die httpd.conf von Apache in <Apache>\confs
• Überprüfen Sie zur Orientierung die PHP-Konfigurationszeilen
• 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 IIS/PWS-Server
• Überprüfen Sie zur Sicherheit die PWS-Konfiguration in Bezug auf PHP
• Legen Sie essai4.php in <IIS-DocumentRoot>\php ab
• Rufe die URL http://localhost/essai4.php auf

2.4.5. Ein JSP- -Skript

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:

Die 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.4.6. Eine ASP.NET-Seite

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 generiert dieses Skript die folgende Seite:

Für diesen Test ist ein Windows-Rechner erforderlich, auf dem die .NET-Plattform installiert ist (siehe Anhang).

• Legen Sie das Skript heure1.aspx in <IIS-DocumentRoot> ab
• Starten Sie den IIS/CASSINI-Server
• Rufen Sie die URL http://localhost/heure1.aspx auf

2.4.7. 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.

2.5. 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.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 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></script> dienen dazu, Skripte innerhalb einer HTML-Seite abzugrenzen. Diese Skripte können in verschiedenen Sprachen geschrieben sein, und das language-Attribut des <script>-Tags gibt die verwendete Sprache an. In diesem Fall ist es 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 verrät es uns:

         <input type="button" value="OK" name="cmdOK" onclick="reagir">

Das onclick-Attribut 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 ist in der Lage, VBScript-Skripte auszuführen. Netscape benötigt hierfür Add-ons. Wir können die folgenden Tests durchführen:

• Apache-Server
• vbs1.html-Skript in <apache-DocumentRoot>
• Rufen Sie die URL http://localhost/vbs1.html mit Internet Explorer auf

• IIS/PWS-Server
• vbs1.html-Skript in <pws-DocumentRoot>
• Rufen Sie die URL http://localhost/vbs1.html mit Internet Explorer auf

Eine Webseite mit einem JavaScript-Skript, auf der Browserseite

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>

Diese Seite ist identisch mit der vorherigen, 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 dieses Codes führt zu denselben Ergebnissen:

Die Tests

• Apache-Server
• Skript „js1.html“ in <apache-DocumentRoot>
• Rufen Sie die URL http://localhost/js1.html mit Internet Explorer oder Netscape auf

• IIS/PWS-Server
• Skript „js1.html“ in <pws-DocumentRoot>
• Rufen Sie die URL http://localhost/js1.html mit Internet Explorer oder Netscape auf

2.6. Client-Server-Kommunikation

Kehren wir zu unserem ursprünglichen Diagramm zurück, das die Komponenten einer Webanwendung veranschaulicht:

Server-Rechner

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 zu betrachten.

2.6.1. Das OSI-Modell

Das offene Netzwerkmodell, bekannt als OSI (Open Systems Interconnection Reference Model), definiert von der ISO (International Organization for Standardization), 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 unterschiedlichen 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 geschah.

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:

Physikalische	Gewährleistet die Übertragung von Bits über ein physikalisches Medium. Diese Schicht umfasst Datenverarbeitungs-Endgeräte (DPTE) wie Terminals oder Computer sowie Datenkreis-Abschlussgerä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).
Datenverbindungsschicht	Verbirgt die physikalischen Eigenschaften der physikalischen Schicht. Erkennt und korrigiert Übertragungsfehler.
Netzwerk	Verwaltet den Weg, den über das Netzwerk gesendete Informationen nehmen müssen. Dies wird als Routing bezeichnet: die Bestimmung der Route, die Informationen nehmen müssen, um ihr Ziel zu erreichen.
Transport	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.
Sitzung	Diese Schicht bietet Dienste, die es einer Anwendung ermöglichen, eine Arbeitssitzung auf einem Remote-Rechner zu eröffnen und aufrechtzuerhalten.
Präsentation	Ziel ist es, die Darstellung von Daten auf verschiedenen Rechnern zu vereinheitlichen. Daher werden Daten, die von Rechner A stammen, von der Präsentationsschicht von Rechner A gemäß einem Standardformat „aufbereitet“, 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.
Anwendung	Auf dieser Ebene finden wir Anwendungen, die im Allgemeinen nah am Benutzer sind, wie E-Mail oder Dateiübertragung.

2.6.2. Das TCP/IP-Modell

Das OSI-Modell ist ein Idealmodell. Die TCP/IP-Protokollsuite nähert sich diesem wie folgt 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 deckt die Funktionen der Schichten 5 bis 7 des OSI-Modells ab.

Webanwendungen befinden sich in der Anwendungsschicht und stützen sich daher auf TCP/IP-Protokolle. Die Anwendungsschichten der Client- und Server-Rechner tauschen Nachrichten aus, die dann an die Schichten 1 bis 4 des Modells weitergeleitet werden, um an ihr Ziel geroutet 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 stellt, sendet er

1. Textzeilen im HTTP-Format, um anzugeben, was er möchte
2. eine Leerzeile
3. optional ein Dokument

Server --> Client

Wenn der Server dem Client antwortet, sendet er

1. Textzeilen im HTTP-Format, um anzugeben, was er sendet
2. eine Leerzeile
3. 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:

1. 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.
2. 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.
3. 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.
4. 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.6.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.6.3.1. Die Antwort eines HTTP-Servers

Hier untersuchen wir, 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:

protocole://machine[:port]/chemin/infos

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 übermittelt werden, um die Anfrage des Clients zu spezifizieren

Was macht ein Browser, wenn ein Benutzer das Laden einer URL anfordert?

1. 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 eingerichtet 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.
2. 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
3. Der Server antwortet auf die gleiche Weise und über dieselbe Verbindung
4. 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 ein Tool namens curl. Curl ist eine DOS-Anwendung, mit der Sie als Client für Internetdienste fungieren können, die verschiedene Protokolle unterstützen (HTTP, FTP, TELNET, GOPHER usw.). Curl ist unter der URL http://curl.haxx.se/ verfügbar. Hier laden wir vorzugsweise die Windows-Version win32-nossl herunter, da die Version win32-ssl zusätzliche DLLs erfordert, die nicht im Curl-Paket enthalten sind. Dieses Paket enthält eine Reihe von Dateien, die lediglich in einen Ordner extrahiert werden müssen, den wir fortan <curl> nennen werden. Dieser Ordner enthält eine ausführbare Datei namens [curl.exe]. Dies wird unser Client für die Abfrage von Webservern sein. Öffnen Sie ein Eingabeaufforderungsfenster und wechseln Sie 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 ein beliebiger Server sein. Hier wollen wir die Kommunikation zwischen dem Curl-Webclient und dem Webserver untersuchen. Zuvor haben wir 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/aspnet/chap1/statique1.html. Der Webserver ist also localhost (=lokaler Rechner) auf Port 80. Wenn wir den HTML-Quellcode dieser Webseite anzeigen (Ansicht/Quelltext), sehen wir den ursprünglich erstellten HTML-Text:

Nun verwenden wir unseren CURL-Client, um dieselbe 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 eine Reihe von Textzeilen gesendet hat, die den HTML-Code für die angeforderte Seite darstellen. Wir haben bereits erwähnt, dass die Antwort eines Webservers folgende Form hat:

Hier haben wir jedoch die HTTP-Header nicht gesehen. Das liegt daran, dass [curl] sie standardmäßig nicht anzeigt. Mit der Option --include können Sie sie anzeigen:

E:\curl2>curl --include http://localhost/aspnet/chap1/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

HTTP/1.1 200 OK	Der Server gibt an , dass er HTTP Version 1.1 unterstützt dass er über die angeforderte Ressource verfügt (Code 200, Meldung OK)
Server:	Der Server identifiziert sich. Hier handelt es sich um einen Cassini-Server
Datum: ...	Datum und Uhrzeit der Antwort
X-ASPNet-Version: ...	spezifischer Header des Cassini-Servers
Cache-Control: public	liefert dem Client Informationen darüber, ob die an ihn gesendete Antwort zwischengespeichert werden kann. Das Attribut [public] teilt dem Client mit, dass er die Seite zwischenspeichern darf. Ein Attribut [no-cache] hätte dem Client mitgeteilt, die Seite nicht zu zwischenspeichern.
ETag:	...
Content-type: text/html	Der Server gibt an, dass er Text im HTML-Format sendet.
Content-Length: 161	Die Anzahl der Bytes im Dokument, das nach den HTTP-Headern gesendet wird. Diese Zahl entspricht tatsächlich der Dateigröße in Bytes der Datei essai1.html: dos>dir test1.html 08.07.2002 10:00 161 test1.html
Connection: close	Der Server gibt an, dass er die Verbindung schließen wird, sobald das Dokument gesendet wurde

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 sehen wir die HTML-Datei in ihrer ursprünglichen Form. 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 [curl]-Client, 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 HTML-Dokument. 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 4052 Byte groß:

dos>dir univ01.gif
23/03/2004  08:14             4 052 univ01.gif

Nun verwenden wir den [curl]-Client:

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

Beachten Sie die folgenden Punkte im oben dargestellten Anfrage-Antwort-Zyklus:

--head	Wir fordern nur die HTTP-Header der Ressource an. Der Grund dafür ist, dass ein Bild eine Binärdatei und keine Textdatei ist und die Anzeige als Text auf dem Bildschirm nichts Lesbares ergibt.
Content-Length: 4052	Dies ist die Größe der Datei univ01.gif
Content-Type: image/gif	Der Server teilt dem Client mit, dass er ein Dokument vom Typ image/gif senden wird, d. h. ein Bild im GIF-Format. Wäre das Bild im JPEG-Format gewesen, hätte der Dokumenttyp image/jpeg gelautet. Dokumenttypen sind standardisiert und werden als MIME-Typen (Multi-purpose Mail Internet Extension) bezeichnet.

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 zu erhalten? In den vorherigen Beispielen haben wir gesehen, was der Client empfangen hat, aber nicht, was der Client gesendet hat. Wir werden die Option [--verbose] von curl verwenden, um auch zu sehen, was der Client an den Server sendet. Beginnen wir mit der Anforderung 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 [curl]-Client eine TCP/IP-Verbindung zum Port 80 auf dem Localhost-Rechner (=127.0.0.1) auf

* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80

Sobald die Verbindung hergestellt ist, sendet er seine HTTP-Anfrage. Dabei handelt es sich um eine Folge von Textzeilen, die mit einer Leerzeile endet:

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 HTTP-Anfrage eines Web-Clients hat zwei Funktionen:

• die gewünschte Ressource anzugeben. Dies ist die Aufgabe der ersten Zeile, GET
• Informationen über den anfragenden Client bereitzustellen, damit der Server seine Antwort möglicherweise auf diesen spezifischen Client-Typ zuschneiden kann.

Die Bedeutung der oben vom Client [curl] gesendeten Zeilen ist wie folgt:

GET Ressource Protokoll	um eine bestimmte Ressource unter Verwendung einer bestimmten Version des HTTP-Protokolls anzufordern. Der Server sendet eine Antwort im HTTP-Format, gefolgt von einer Leerzeile und der angeforderten Ressource
User-Agent	, um anzugeben, wer der Client ist
host:machine:port	zur Angabe (HTTP 1.1-Protokoll) des Rechners und des Ports des abgefragten Webservers
Pargma	hier, um anzugeben, dass der Client kein Caching unterstützt.
Accept	MIME-Typen, die die Dateitypen angeben, die der Client verarbeiten kann

Versuchen wir den Vorgang noch einmal 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 konzentrieren uns ausschließlich auf die vom Client 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 GET-Befehls haben wir nun einen HEAD-Befehl. Dieser Befehl fordert, dass die Antwort des Servers auf HTTP-Header beschränkt bleibt und dass die angeforderte Ressource nicht gesendet wird. Der obige Screenshot zeigt die empfangenen HTTP-Header nicht an. Diese wurden mit der Option [--output response.txt] des Befehls [curl] in einer Datei gespeichert:

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

Wir haben anhand einiger Beispiele die Struktur der Anfrage eines Web-Clients und die Antwort des Web-Servers darauf untersucht. Die Kommunikation erfolgt über das HTTP-Protokoll, eine Reihe von textbasierten Befehlen, die zwischen den beiden Parteien ausgetauscht werden. Die Anfrage des Clients und die Antwort des Servers weisen folgende Struktur auf:

Bei einer Client-Anfrage (oft als „Query“ bezeichnet) fehlt der Abschnitt [Document] in der Regel. Es ist jedoch möglich, dass ein Client ein Dokument an den Server sendet. Dies geschieht mithilfe eines Befehls namens PUT. Die beiden gängigen Befehle zum Anfordern einer Ressource sind GET und POST. Letzterer wird etwas später behandelt. Der Befehl HEAD wird verwendet, um nur die HTTP-Header anzufordern. Die Befehle GET und POST werden von browserbasierten Web-Clients am häufigsten verwendet.

Als Antwort auf die Anfrage eines Clients sendet der Server eine Antwort mit derselben Struktur. Die angeforderte Ressource wird im Abschnitt [Document] übertragen, es sei denn, der Befehl des Clients war HEAD; in diesem Fall werden nur die HTTP-Header gesendet.

2.7. HTML

Ein Webbrowser kann verschiedene Dokumente anzeigen, wobei das HTML-Dokument (HyperText Markup Language) am häufigsten vorkommt. Dabei handelt es sich um formatierten Text, der Tags der Form <tag>text</tag> verwendet. So wird der Text <B>important</B> den Text „important“ in Fettdruck anzeigen. Es gibt eigenständige Tags wie das -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 zu schreiben. 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 ansehen, 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.

Kurz gesagt: Sie müssen nicht die gesamte HTML-Sprache beherrschen, 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.7.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:

<html>
    <head>
        <title>Un titre</title>
        ...
    </head>
    <body attributs>
        ...
    </body>
</html>

Das gesamte Dokument ist von den Tags <html>...</html> umschlossen. Es besteht aus zwei Teilen:

1. <head>...</head>: Dies ist der nicht sichtbare Teil des Dokuments. Er liefert Informationen an den Browser, der das Dokument anzeigt. Er enthält oft die Tags <title>...</title>, die den Text festlegen, 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.
2. <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 Punkte hervorgehoben:

HTML	HTML-Tags und Beispiele
Dokumenttitel	<title>Tags</title> Der Text erscheint in der Titelleiste des Browsers, wenn das Dokument angezeigt wird
Horizontale Linie	<horizontal> : zeigt eine horizontale Linie an
Tabelle	<table attributes>....</table> : zum Definieren der Tabelle <tr attributes>... : zum Definieren einer Zeile <td attributes>... : zum Definieren einer Zelle Beispiele: <table border="1">... : Das Attribut „border“ definiert die Dicke des Tabellenrandes <td valign="middle" align="center" width="150">Zelle(1,2) : definiert eine Zelle, deren Inhalt Zelle(1,2) sein wird. Dieser Inhalt wird vertikal (valign="middle") und horizontal (align="center") zentriert. Die Zelle hat eine Breite von 150 Pixeln (width="150")
Bild	<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.
link	<a href="http://istia.univ-angers.fr">here: bewirkt, dass der Text „here“ als Link zur URL http://istia.univ-angers.fr dient.
Seitenhintergrund	<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 stellen muss:

1. http://localhost:81/html/balises.htm, um den HTML-Quellcode des Dokuments abzurufen
2. http://localhost:81/images/univ01.gif, um das Bild univ01.gif abzurufen
3. 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 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 Zuordnung von visuellen Elementen zu HTML-Tags lautet wie folgt:

Visuelles Steuerelement	HTML-Tag
Formular	<form method="POST" >
Eingabefeld	<input type="text" name="txtInput" size="20" value="ein paar Wörter">
verdecktes Eingabefeld	<input type="password" name="txtPassword" size="20" value="aPassword">
Mehrzeiliges Eingabefeld	<textarea rows="2" name="inputArea" cols="20"> Zeile 1 Zeile 2 Zeile 3 </textarea>
Optionsfelder	<input type="radio" value="Ja" name="R1">Ja <input type="radio" name="R1" value="Nein" checked>Nein
Kontrollkästchen	<input type="checkbox" name="C1" value="one">1 <input type="checkbox" name="C2" value="zwei" checked>2 <input type="checkbox" name="C3" value="drei">3
Dropdown	<select size="1" name="cmbValues"> <option>Auswahl1</option> <option selected>Option2</option> <option>Option3</option> </select>
Einfachauswahlliste	<select size="3" name="lst1"> <option selected>Liste1</option> <option>Liste2</option> <option>Liste3</option> <option>Liste4</option> <option>Liste5</option> </select>
Mehrfachauswahlliste	<select size="3" name="lst2" multiple> <option>list1</option> <option>list2</option> <option selected>list3</option> <option>list4</option> <option>list5</option> </select>
Absenden-Schaltfläche	<input type="submit" value="Absenden" name="cmdSubmit">
Zurücksetzen-Schaltfläche	<input type="reset" value="Zurücksetzen" name="cmdReset">
Schaltfläche	<input type="button" value="Löschen" name="cmdClear" onclick="clear()">

Sehen wir uns diese verschiedenen Steuerelemente einmal an.

2.7.1.1. Das Formular

Formular

<form method="POST" >

HTML-Tag

<form name="..." method="..." action="...">...</form>

Attribute

name="exampleform": Formularname method="..." : Methode, die vom Browser verwendet wird, 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 durch die 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 die Tastatur oder die Maus eingegebene Informationen zu erfassen und an eine Webserver-URL zu senden. An welche? 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 uns den Web-Client immer so vorgestellt, dass er Informationen von einem Webserver „anfordert“, niemals aber Informationen an diesen „übermittelt“. Wie übermittelt 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>, bei dem method auf GET oder POST gesetzt 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.7.1.2. Eingabefeld

Eingabefeld

<input type="text" name="txtInput" size="20" value="some words"> <input type="password" name="txtMdp" size="20" value="aPassword">

HTML-Tag

<input type="..." name="..." size=".." value=".."> Das input-Tag existiert für verschiedene Steuerelemente. Es ist das type-Attribut, das diese verschiedenen Steuerelemente voneinander unterscheidet.

Attribute

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 für die 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.7.1.3. Mehrzeiliges Eingabefeld

Mehrzeiliges Eingabefeld

<textarea rows="2" name="areaSaisie" cols="20"> Zeile 1 Zeile 2 Zeile 3 </textarea>

HTML-Tag	<textarea ...>text</textarea> zeigt ein mehrzeiliges Texteingabefeld mit Starttext an
Attribute	rows="2": Anzahl der Zeilen cols="'20": Anzahl der Spalten name="areaSaisie": Name des Steuerelements

2.7.1.4. Optionsfelder

Optionsfelder

<input type="radio" value="Yes" name="R1">Ja <input type="radio" name="R1" value="no" checked>Nein

HTML-Tag

<input type="radio" attribute2="value2" ....>text Zeigt ein Optionsfeld mit Text daneben an.

Attribute

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 Radiobutton zugewiesener Wert. Verwechsle diesen Wert nicht mit dem Text, der neben dem Radiobutton 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.7.1.5. Kontrollkästchen

Checkboxen

<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

HTML-Tag

<input type="checkbox" attribute2="value2" ....>text zeigt ein Kontrollkästchen mit Text daneben an.

Attribute

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. aktiviert: Ist dieses Schlüsselwort vorhanden, ist das Optionsfeld aktiviert; andernfalls ist es nicht aktiviert.

2.7.1.6. Dropdown-Liste (Kombinationsfeld)

Combo

<select size="1" name="cmbValues"> <option>Auswahl1</option> <option selected>Option2</option> <option>Option3</option> </select>

HTML-Tag

<select size=".." name=".."> <option [selected]>...</option> ... </select> zeigt den Text zwischen den Tags <option>...</option> in einer Liste an

Attribute

name="cmbValues": Name des Steuerelements. size="1": Anzahl der sichtbaren Listenelemente. size="1" macht die Liste zu einem Kombinationsfeld. selected: Wenn dieses Attribut 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.7.1.7. Liste mit Einzelauswahl

Liste mit Einzelauswahl

<select size="3" name="lst1"> <option selected>list1</option> <option>list2</option> <option>Liste3</option> <option>Liste4</option> <option>Liste5</option> </select>

HTML-Tag	<select size=".." name=".."> <option [selected]>...</option> ... </select> zeigt den Text zwischen den Tags <option>...</option> in einer Liste an
Attribute	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.7.1.8. Mehrfachauswahlliste

Einzelauswahlliste

<select size="3" name="lst2" multiple> <option selected>list1</option> <option>list2</option> <option selected>Liste3</option> <option>Liste4</option> <option>list5</option> </select>

HTML-Tag	<select size=".." name=".." multiple> <option [selected]>...</option> ... </select> zeigt den Text zwischen den Tags <option>...</option> in einer Liste an
Attribute	multiple: ermöglicht die Auswahl mehrerer Elemente aus der Liste. Im obigen Beispiel sind die Elemente list1 und list3 beide ausgewählt.

2.7.1.9. Button

Schaltfläche

<input type="button" value="Löschen" name="cmdClear" onclick="clear()">

HTML-Tag

<input type="button" value="..." name="..." onclick="clear()" ....>

Attribute

type="button": Definiert ein Schaltflächenelement. 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: <script language="JavaScript"> function clear(){ alert("Sie haben auf die Schaltfläche „Löschen“ geklickt"); }//clear </script> Die Funktion „clear“ zeigt eine Meldung an:

2.7.1.10. Schaltfläche „Senden“

Senden-Schaltfläche

<input type="submit" value="Senden" name="cmdSend">

HTML-Tag	<input type="submit" value="Senden" name="cmdRenvoyer">
Attribute	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.7.1.11. Zurücksetzen-Schaltfläche

Zurücksetzen-Schaltfläche

<input type="reset" value="Zurücksetzen" name="cmdReset">

HTML-Tag	<input type="reset" value="Zurücksetzen" name="cmdReset">
Attribute	type="reset": Definiert die Schaltfläche als Formular-Reset-Schaltfläche. Wenn der Benutzer auf diese Schaltfläche klickt, setzt 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

verstecktes Feld

<input type="hidden" name="secret" value="aValue">

HTML-Tag

<input type="hidden" name="..." value="...">

Attribute

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 den Quellcode in seinem Browser anzeigen, sähe er das Tag <input type="hidden" value="..."> und somit den Wert des versteckten Feldes. 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.7.2. Senden von Formularwerten an einen Webserver durch einen Webclient

In der vorherigen Lektion 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 GET- und die POST-Methode. Sehen wir uns ein Beispiel an, um den Unterschied zwischen den beiden Methoden zu verdeutlichen. Die zuvor besprochene Seite ist eine statische Seite. Um auf die HTTP-Header zuzugreifen, die vom Browser gesendet werden, der dieses Dokument anfordert, wandeln wir sie in eine dynamische Seite für einen .NET-Webserver (IIS oder Cassini) um. Der Schwerpunkt liegt hier nicht auf der .NET-Technologie – die im nächsten Kapitel behandelt wird –, sondern auf der Client-Server-Kommunikation. Der Code für die ASP.NET-Seite 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)
      ' save the query
    saveRequest
  end sub
  Private Sub saveRequest
      ' saves the current query in request.txt of the page folder
    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");
      }//effacer
        </script>
    </head>
    <body background="/images/standard.jpg">
....
    </body>
</html>

Zum HTML-Inhalt der betreffenden Seite fügen wir einen Abschnitt mit VB.NET-Code hinzu. Wir werden diesen Code nicht näher erläutern, außer um zu sagen, dass der Webserver bei jedem Aufruf des obigen Dokuments die Anfrage des Webclients in der Datei [request.txt] im Ordner des aufgerufenen Dokuments speichert.

2.7.2.1. GET-Methode

Führen wir einen ersten Test durch, bei dem im HTML-Code des Dokuments das FORM-Tag wie folgt definiert ist:

        <form method="get">

Das vorstehende Dokument (HTML+VB-Code) trägt den Namen [params.aspx]. Es befindet sich in der Verzeichnisstruktur eines .NET-Webservers (IIS/Cassini) und ist über die URL http://localhost/aspnet/chap1/params.aspx erreichbar:

Der Browser hat gerade 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 sehen Elemente, die wir bereits vom [curl]-Client kennen. Andere tauchen zum ersten Mal auf:

Connection: keep-alive	Der Client bittet den Server, die Verbindung nach seiner Antwort nicht zu schließen. Dadurch kann er dieselbe Verbindung für eine nachfolgende Anfrage nutzen. Die Verbindung bleibt nicht unbegrenzt offen. Der Server schließt sie nach einer längeren Zeit der Inaktivität.
Keep-Alive	Dauer in Sekunden, während der die [Keep-Alive]-Verbindung offen bleibt
Accept-Charset	Zeichensatz, den der Client verarbeiten kann
Accept-Language	Liste der vom Client bevorzugten Sprachen.

Wir füllen das Formular wie folgt aus:

Wir verwenden die Schaltfläche [Absenden] oben. Der HTML-Code lautet wie folgt:

<form method="get">
    ...
    <input type="submit" value="Envoyer">
    ...
</form>

Wenn auf die Schaltfläche [Absenden] geklickt wird, sendet der Browser die Formularparameter (das <form>-Tag) an die im [action]-Attribut des <form action="URL">-Tags angegebene URL, sofern diese vorhanden ist. Ist dieses Attribut nicht vorhanden, werden die Formularparameter an die URL gesendet, von der das Formular bereitgestellt wurde. Dies ist hier der Fall. Die Schaltfläche [Submit] sollte daher eine Anfrage des Browsers an die URL [http://localhost/aspnet/chap1/params.aspx] auslösen, wobei die Formularparameter enthalten sind. Da die Seite [params.aspx] die empfangene Anfrage speichert, sollten wir feststellen können, wie der Client diese Parameter übermittelt hat. Probieren wir es aus. Wir klicken auf die Schaltfläche [Submit]. Wir erhalten die folgende Antwort vom Browser:

Dies ist die Startseite, aber Sie können sehen, dass sich die URL im [Adressfeld] des Browsers geändert hat. Sie lautet nun wie folgt:

http://localhost/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

Wir sehen, dass sich die im Formular getroffenen Auswahlen in der URL widerspiegeln. 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

Wir sehen eine HTTP-Anfrage, die derjenigen sehr ähnlich ist, die der Browser ursprünglich gestellt hat, als er das Dokument ohne Parameter angefordert hat. Es gibt zwei Unterschiede:

GET HTTP/1.1 URL	Die Formularparameter wurden in der Form ?param1=val1&param2=val2&... an die Dokument-URL angehängt
Referer	Der Client verwendet diesen HTTP-Header, um die URL des Dokuments anzugeben, das er bei der Anfrage angezeigt hat

Schauen wir uns einmal genauer an, wie die Parameter in der GET-Anfrage URL?param1=value1&param2=value2&... HTTP/1.1 übergeben wurden, wobei param1, param2 usw. die Namen der Webformular-Steuerelemente und value1, value2 usw. die ihnen zugeordneten Werte sind. 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 Wörter">		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>		Eingabebereich=die+Grundlagen+der+Web%0D%0A Webprogrammierung - vom Benutzer in das Eingabefeld eingegebener Text. %OD%OA ist das Zeilenendezeichen. Leerzeichen wurden durch das +-Zeichen ersetzt
<select size="1" name="cmbValues"> <option>Auswahl1</option> <option selected>Auswahl2</option> <option>Auswahl3</option> </select>		cmbValues=option3 - vom Benutzer aus der Einfachauswahlliste ausgewählter Wert
<select size="3" name="lst1"> <option selected>list1</option> <option>list2</option> <option>Liste3</option> <option>Liste4</option> <option>list5</option> </select>		lst1=list3 - vom Benutzer aus der Einfachauswahlliste ausgewählter Wert
<select size="3" name="lst2" multiple> <option selected>list1</option> <option>list2</option> <option selected>list3</option> <option>list4</option> <option>list5</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

Sie fragen sich vielleicht, was der Server mit den an ihn übergebenen Parametern gemacht hat. Eigentlich gar nichts. Nach Erhalt der Anfrage

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

Der Webserver hat die Parameter in der URL an das Dokument http://localhost/aspnet/chap1/params.aspx weitergeleitet, d. h. an das Dokument, das wir ursprünglich erstellt haben. Wir haben keinen Code geschrieben, um die vom Client gesendeten Parameter abzurufen und zu verarbeiten. Es läuft also alles so ab, als ob die Anfrage des Clients einfach lauten würde:

GET /aspnet/chap1/params.aspx

Deshalb haben wir als Reaktion auf unseren [Submit]-Button dieselbe Seite erhalten, die ursprünglich durch die Anfrage der URL [http://localhost/aspnet/chap1/params.aspx] ohne Parameter abgerufen wurde.

2.7.2.2. POST-Methode

Das HTML-Dokument ist nun so konfiguriert, dass der Browser die POST-Methode verwendet, um die Formularwerte an den Webserver zu senden:

    <form method="POST" >

Wir rufen das neue Dokument über die URL [http://localhost/aspnet/chap1/params.aspx] auf, füllen das Formular wie bei der GET-Methode aus und senden die Parameter über die Schaltfläche [Submit] an den Server. Wir erhalten die folgende Antwortseite vom Server:

Wir erhalten somit das gleiche Ergebnis wie bei der GET-Methode, d. h. die Startseite. Beachten Sie einen Unterschied: Im [Adressfeld] des Browsers werden die übermittelten Parameter nicht angezeigt. Sehen wir uns nun die vom Client gesendete und in der Datei [request.txt] gespeicherte Anfrage an:

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 HTTP-Anfrage des Clients erscheinen neue Elemente:

POST HTTP/1.1	Die GET-Anfrage wurde durch eine POST-Anfrage ersetzt. Die Parameter stehen nicht mehr in der ersten Zeile der Anfrage. Wir sehen, dass sie nun nach einer Leerzeile hinter der HTTP-Anfrage stehen. Ihre Kodierung ist identisch mit der in der GET-Anfrage.
Content-Length	Anzahl der „gesendeten“ Zeichen, d. h. die Anzahl der Zeichen, die der Webserver nach dem Empfang der HTTP-Header lesen muss, um das vom Client gesendete Dokument abzurufen. Bei dem hier betreffenden Dokument handelt es sich um die Liste der Formularwerte.
Content-type	Gibt den Typ des Dokuments an, das der Client nach den HTTP-Headern sendet. Der Typ [application/x-www-form-urlencoded] zeigt an, dass es sich um ein Dokument handelt, das Formularwerte enthält.

Es gibt zwei Methoden zur Datenübertragung an einen Webserver: GET und POST. 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&param2=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. Fazit

In diesem Kapitel wurden verschiedene Grundkonzepte der Webentwicklung vorgestellt:

• die verschiedenen verfügbaren Tools und Technologien (Java, ASP, ASP.NET, PHP, Perl, VBScript, JavaScript)
• die Client-Server-Kommunikation über das HTTP-Protokoll
• das Entwerfen eines Dokuments mit HTML
• die Gestaltung von Eingabeformularen

Wir haben ein Beispiel gesehen, wie ein Client Informationen an den Webserver senden kann. Wir haben nicht behandelt, wie der Server

• diese Informationen abrufen
• diese verarbeiten
• dem Client eine dynamische Antwort basierend auf dem Ergebnis der Verarbeitung senden

Dies ist der Bereich der Webprogrammierung, ein Thema, das wir im nächsten Kapitel mit einer Einführung in die ASP.NET-Technologie behandeln werden.