Content-Type - AG Netzbasierte Informationssysteme

Arbeitsgruppe
Vorlesung Netzbasierte Informationssysteme
Web-basierte
Informationssysteme I
Prof. Dr. Adrian Paschke
Arbeitsgruppe Corporate Semantic Web (AG-CSW)
Institut für Informatik, Freie Universität Berlin
[email protected]
http://www.inf.fu-berlin.de/groups/ag-csw/
Übersicht:
 Inhalt
 Protokolle & Ports
 Kommunikation über HTTP
 Realisierung dynamischer WebAnwendungen
 Mehrschichtige Architekturen
Anwendungsprotokolle
ISO/OSI
TCP/IP
Application Layer
Presentation Layer
Application
Layer
Standards &
Protokolle
FTP, SMTP,
HTTP, TELNET, …
Session Layer
Transport Layer
Host-To-Host
Transport Layer
Network Layer
Internet Layer
Data Link Layer
Physical Layer
Network Access
Layer
TCP, UDP
IP (mit ICMP, ARP)
IEEE 802.3, X.25 …
Prozesskommunikation über TCP/IP
httpd
80 HTTP
popper
date
110 POP
13 Daytime
TCP
Anwendungsprozeß
Socket - TCP oder UDP,
einem Port zugeordnet
UDP
IP
TCP/IP
Netzwerksoftware
Network Access
Layer
Kartenspezifische
Netzwerksoftware
Protocol-Multiplexing mit Ports
browser
Email
client
date
httpd
popper
date
80 HTTP
110 POP
16 Date
80 HTTP
110 POP
16 Date
TCP
UDP
TCP
UDP
IP
IP
Network Access
Layer
Network Access
Layer
Client
Server
BSP: Emails
SMTP
POP
IMAP
POP
• SMTP (Simple Mail Transfer Protocol,
Port 25) zur Übertragung von Emails
• Mail wird i.d.R. auf einem Mail-Server
zwischengelagert
• Über POP (Post Office Protocol, Port 110)
oder IMAP (Internet Message Access
Protocol) wird auf Mail zugegriffen
• SMTP und POP basieren auf TCP
SMTP, POP
(25, 110)
TCP
IP
Network Access
Layer
BSP: Datenübertragung mit FTP
•
•
•
•
Zuverlässiger und effizienter Dateitransfer
Server-Prozess an den Ports 20 und 21 (TCP)
Klartext-Protokoll (Mit Hilfefunktion)
Binäre (unveränderte) Übertragung von Daten
oder Berücksichtigung unterschiedlicher CR/LFKonventionen (ASCII)
• Weite Verbreitung durch Möglichkeit des
anonymen Zugangs zu dafür vorgesehenen
Dateien (Anonymous-FTP)
GET
PUT
FTP (20, 21)
TCP
IP
RFC 959
RFC 1635
Network Access
Layer
Exkurs: DNS-Namensauflösung (seit 1984)
Root-Name-Server
(derzeit 16 Stück)
Name-Server dns.denic.de
Name-Server der Uni
FU-Berlin
DNS (53)
UDP
IP
Network Access
Layer
217.12.6.16
Inf.fu-berlin.de?
internaldns1.inf.fu-berlin.de
Inf.fu-berlin.de
Exkurs: DNS

Auflösung der Namen zu IP-Adressen und v. v.

Dezentrale, hierarchisch organisierte Datenbank
 große Anzahl von Hosts, leichter zu aktualisieren als
zentraler Datenbestand

Unix: BIND-Service (Berkeley Internet Name Domain)
Ur-Nameserver, heute meistgenutzte Nameserversoftware

Root-Name-Server leiten an Top-level-Domains,
Jede Top-level-Domain (wie .org, .com) leiten an Nameserver
für spezielle Domains weiter, …
 Neue Domains sind bei übergeordneten Domain zu registrieren
 DENIC ist die zentrale Registrierungsstelle für alle Domains unterhalb der Top
Level Domain .de

DNS-Protokoll basiert auf UDP

DNS-Caching - Ergebnisse von früheren Anfragen werden temporär
zwischengespeichert
HTTP - HyperText Transfer Protocol
•
„Einfaches“ Protokoll zur Übertragung von Daten beliebiger Struktur
(Entitäten) über das Internet (TCP/IP); Port: 80 ist für HTTP reserviert
•
Über 75% of Internet backbone traffic über HTTP
•
1989 von Tim Berners-Lee am CERN zusammen mit HTML entwickelt
- > Gilt als WWW-Gründung (HTTP/0.9)
•
•
•
Erweiterung auf andere Datentypen (Content-Types) in
Version HTTP/1.0 (1996: RFC 1945, IETF))
•
•
„Zustandsloses“ Request-Reply-Protokoll (HTTP/0.9)
Einsatzgebiet: Transfer von Hypertext (Inhalt vom Typ text/html)
Datentypen entsprechen dem MIME-Format
(Multipurpose Internet Mail Extensions)
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1 (Aug./96, 99 IETF Standard)
… but: HTTP-related efforts in W3C are continuing
HTTP


Zustandsloses Protokoll
Anfrage mit Antwort beantwortet
HTTP/1.0 (noch verbreitet eingesetzt):
Bsp: Webpage mit Ressourcen
Client
URL
Analyse
Bilder 1
Server
Ressource laden
(HTML)
Ressource laden
Bilder 2
...
...
Bilder n
Ressource laden
Beispiel: HTTP Protokoll
Server-Response-Codes
 …geben den Status der Transaktion an
 Informative Meldungen (1xx)
 Z.B. 100: Continue ( Anfrage wird bearbeitet )
 Client-Request erfolgreich (2xx)
 z.B. 200: OK, 202: Accepted
 Weiterleitung / Umleitung (3xx)
 Z.B. 301: Moved Permanently, 302: Found
 Client-Request unvollständig (4xx)
 Z.B. 401: Unauthorized, 403: Forbidden, 404: Not Found
 Server-Fehler (5xx)
 Z.B.: 500: Internal Server Error, 503: Service Unavailable
Client-Methoden bei HTTP
 Methoden bei verschiedenen HTTP-Versionen:
 HTTP/0.9:
Nur die Methode GET wird unterstützt.
 HTTP/1.0:
Die Methoden HEAD, POST, PUT, DELETE,
(LINK und UNLINK) kommen hinzu.
 HTTP/1.1:
LINK, UNLINK wieder herausgenommen
Hinzu kommen OPTIONS,TRACE und CONNECT.
 http://www.w3.org/Protocols/
Aufbau Anfrage
 Anfrage besteht aus







Anfragemethode
Anfragebeschreibung durch Kopfzeilen
Allgemeine Beschreibungen
Anfragespezifische Beschreibungen
Beschreibung eventuell beiliegenden Inhalts
Leerzeile
Eventueller Inhalt
 Beispiel:
Client-Methoden: GET
 Um Daten vom Server abzurufen


Methode Ressource HTTP/x.y
Resource ist




Absoluter Pfad im Server-Verzeichnisbaum
Voll-qualifizierte URL bei Anfrage an Proxy
*, Authority bei bestimmten Methoden
GET Methode
Get <URI> <Version> <Conditional-Header>:<DATE>
Beantwortet mit Antwortcode, Kopfzeilen, Inhalt
 Beispielanfrage:

Get /index.html HTTP/1.1
Host: www.apache.org
if-Modified-Since: Fri, 29 Oct 2005
13:50:40 GMT
Accept: image/gif, image/jpeg,
image/pjpeg, image/png, text/html
 Beispielantwort:

HTTP/1.1 304 Not Modified
Date: Fri, 29 Oct 2005 13:50:40 GMT
Content-Type: text/html
Expires: Fri, 29 Oct 2005 18:58:40 GMT
<HTML>
<TITLE>
AG CSW
</TITLE>
GET /index.html
...
Content Negotiation und weitere
Headerfelder
 Oft liegen Ressourcen in unterschiedlicher Qualität,
Sprache (EN/DE) oder Kodierung (GIF/JPEG/...) vor
 HTTP ermöglicht die „Aushandlung“ der besten Variante
(Accept-Charset, Accept-Language, ...)
 Zahlreiche weitere Headerfelder:






User-Agent (Browser und Betriebssystem)
Server (Webserver und Betriebssystem)
Referer (Information über die URL der zuletzt besuchten Seite)
Content-Length (Spezifiziert die Länge des Requests)
Content-Type (Spezifiziert den MIME-Type)
…
Allgemeine Kopfzeile in Anfrage und
Antwort
 Date: Tue, 15 Nov 1994 08:12:31 GMT
 Datum des Abschickens der Anfrage im RFC 1123 Format
 Connection: close
 Verbindung nach Ergebnisübermittlung abbauen
 Cache-Control: Direktive
 Steuert das Caching von Anfragen und Antworten
 no-cache: Antwort darf nicht zur Beantwortung anderer Anfragen
genutzt werden
 no-store: Antwort- oder Anfragemitteilungen dürfen nicht gespeichert
werden
 weitere: max-age, max-stale, min-fresh, no-transform, only-ifcached,
public, private, must-revalidate, proxy-revalidate, smaxage
 Pragma: no-cache
 Entspricht Cache-Control: no-cache
 …
Allgemeine Kopfzeile in Anfrage und
Antwort

Transfer-Encoding: Encoding
Wie die Mitteilung für den Transfer kodiert wurde
 chunked: Mitteilung in Teilen geschickt, Zeichenanzahl in initialer Hexzahl
>java HttpGetClient11 focus.msn.de
java HttpGetClient11 focus.msn.de
HTTP/1.1 200 OK
Date: Fri, 25 Nov 2005 13:20:01 GMT
Server: Apache
set-cookie: NGUserID=11329248012594; path=/; domain=.msn.de;
expires=fri, 10-aug-2012 16:48:59 gmt
Transfer-Encoding: chunked
Content-Type: text/html
2e96
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html> <head>
<title>FOCUS Online in Kooperation mit MSN Homepage</title>
…


identity: Mitteilung unkodiert geschickt
gzip, compress, deflate: Komprimierte Übertragung
Anfrage Kopfzeile
 Host: Name
Aus der URL ermittelter Name des Rechners von
dem angefordert wird. Einziger Pflichtkopfzeile in
HTTP 1.1
 If-Modified-Since: Datum
Änderung der Informationseinheit seit Datum
 Ja: 200 und Inhalt schicken
 Nein: 304 und Inhalt nicht schicken
 If-Unmodified-Since: Datum
Änderung der Informationseinheit seit Datum
 Ja: 412 und nicht verarbeiten
 Nein: Normal verarbeiten (als sei If-Unmodified-Since:
nicht vorhanden)
Inhalts-Kopfzeile
 Content-Encoding: Kodierung
Kodierung des Inhalts
 binary, 8bit, 7bit, quoted-printable, base64, …
 Content-Type: Medienart
 Medientyp des Inhalts
 text/html, image/gif, ..
 Content-Language: Sprachkürzel
 Sprache des Inhalts
 de, en, en-US
 Content-Length: Länge
Länge des Inhalts in Byte
 Content-Range: Range
Beschreibung des Ausschnitts bei Teilanforderung
Inhalts-Kopfzeile
 Content-Location: URI
Verweis auf eigentlichen Inhalt
 Content-MD5: MD5Checksum
Message Digest für Inhalt zur Integritätsprüfung
 Expires: Datum
Kann nach Datum aus Caches gelöscht werden
 Last-Modified: Datum
Letzte Änderung
Inhaltstypen
 Per HTTP können beliebige Inhalte transportiert
werden, nicht nur HTML
 Multipurpose Internet Mail Extensions MIME
(RFC 2045, RFC 2046)
definiert ein Schema zur eindeutigen Benennung durch
einen Inhaltstypen
 In HTTP in Kopfzeile Content-Type
 Format: Typ/Untertyp
 text/html
 image/jpeg
 vnd.motorola.video
MIME Typen
 Acht Typen:
 text: Text
 text/plain, text/html, text/rtf, text/vnd.latex-z
 image: Grafiken
 image/png, vnd.microsoft.icon
 video: Bewegtbilder
 video/mpeg, video/quicktime, video/vnd.vivo
 audio: Audiodaten
 audio/G726-16 , audio/vnd.nokia.mobile-xmf
 application: binäre und/oder anwendungsspezifische Daten
 application/EDIFACT, application/vnd.ms-powerpoint
 multipart: mehrteilige Daten
 multipart/mixed
 message: Nachrichten
 message/rfc822
 model: Daten
 model/vrml
MIME Typen
 MIME Typen
 MIME-Typen werden von der Internet Corporation for
Assigned Names and Numbers IANA verwaltet
 http://www.iana.org/assignments/media-types/
 Verarbeiten eines bestimmten Medientyps nach
Erhalt:
 Teil der Anwendung (siehe auch:
javax.mail.internet.MimeMessage)
 eventuell Unterstützung durch Betriebssystem
 Ermittlung des MIME-Typs für eine Datei:
 Ableitung aus Endung
(javax.activation.MimetypesFileTypeMap)
 Ableitung aus Inhalt der Datei
Client-Methode: POST
 wird benutzt, um (meist Formular) Daten an ein
Programm auf dem Server zu senden
 Post /test.cgi HTTP/1.1
Accept: */*
Accept-Language: en-us
Content-Type: application/x-www-form
User-Agent: Mozilla/5.0
Host: www.apache.org
Content-Length: 39
vorname=Peter&name=Mayer&submit=Request
 Server sendet die Ergebnis-Daten des
Programms dann zurück an den Client
Weitere Client-Methoden

HEAD
 liefert gleiche Header-Information wie GET und POST

DELETE, PUT
 Funktionen wie bei FTP

TRACE (HTTP/1.1)
 um zu überprüfen, ob die Nachricht richtig ankommt; liefert den Transportweg (z.B.
mit Proxy), liefert die Anfrage so zurück, wie der Server sie empfangen hat.

OPTIONS (HTTP/1.1)
 um die auf dem Server möglichen Funktionen abzufragen

CONNECT (HTTP/1.1)
 um sich mit einem HTTPS-Server zu verbinden (SSL Tunnel)
HTTP/1.0 Problembereiche
-> HTTP 1.1
 Keine Unterstützung für non-IP-based virtual Hosts
 d.h. mehrere Web Server laufen auf einer physikalischen
Maschine mit einer IP-Adresse & einem Port (80)
 Pro Request eine neue TCP/IP Verbindung (zustandslos)
 Unsichere Nutzer Authentifizierung (basic authentication)
 einfaches <user>:<password>-Schema
 Base64 kodiert, aber keine Verschlüsselung
 (Daneben: Caching Probleme bei Proxies,
nur eingeschränktes Content Negotiation,…)
Virtual Hosts - Lösungsansätze
 Verschiedene Serverports (ab HTTP/0.9)
 jeder Webserver bekommt einen eigenen Port
 nur einer kann den Standardport 80 verwenden
 IP-based virtual Hosts (ab HTTP/0.9)
 dem Rechner werden mehrere IP-Adressen zugewiesen
 jeder Webserver bzw. Domäne erhält eine eigene IP-Adresse
 Problem: „Verschwendung“ von IP-Adressen
 Non-IP-based virtual Hosts (ab HTTP/1.1)
 Auf Maschine (eine IP-Nummer, ein Port) laufen mehrere
Webserver
 Auf Grund der HTTP-Anfrage wird entschieden, welche Ressource
(aus welcher Domain) angefragt wird
Non-IP-based Virtual Hosts
GET /dir1/structure.xml HTTP/1.1
Host: www.firma1.com
GET /home.cgi HTTP/1.1
Host: www.firma2.com
IP: 131.159.224.211
GET /index.html HTTP/1.1
Host: www.firma3.com
• HTTP-Requests verwenden Headerfeld Host
• Eine HTTP/1.1-Anfrage ohne dieses Feld führt zu einem Fehler
• Alle Domains auf Server werden auf gleiche IP-Adresse abgebildet
• Domainauswahl über Host nicht durch den Aufbau der TCP-Verbindung
HTTP/1.1 persistente Verbindungen
Client
Server
Open TCP
URL
Analyse
Bilder 1
Ressource laden
(HTML)
Ressource laden
Bilder 2
...
...
Bilder n
Ressource laden
Close TCP
Wiederverwendung einer Verbindung spart CPU-Zyklen und Bandbreite
Partieller Transfer von Ressourcen
 Übertragung sehr großer Dateien in einzelnen Blöcken
 Wiederholung von abgebrochenen Übertragungen
 Nur der Teil, der fehlt muss übertragen werden
 Parallele Übertragung von Teilen einer großen Datei
 Range: <x-y bytes>
Client
Open
Get /large.zip
Close
Server
Apache httpd.conf
 „KeepAlive“
 legt fest, ob persistente Verbindungen zulässig sind. Wird mit "Off"
deaktiviert
 "MaxKeepAliveRequests":
 die Höchstzahl der während einer persistenten Verbindung
zulässigen Anfragen. Wird 0 angegeben, ist unbegrenzter Zugriff
möglich.
 "KeepAliveTimeout":
 Zeitspanne (Zahl an Sekunden), um auf die nächste Abfrage
desselben Clients mit derselben Verbindung zu warten.
 "MaxClients":
 Höchstzahl der gleichzeitig laufenden Server. Damit wird auch die
Zahl der Clients eingegrenzt, die simultan mit dem Server
verbunden werden können.
Caching/Proxies
 Cache – MISS – die angefragte Ressource ist nicht im
Cache, bzw. HIT im Erfolgsfall
GET http://inf.fu-berlin.de/people/paschke.html HTTP/1.1
host: inf.fu-berlin.de
HTTP/1.0 200 OK
Date: Tue, 30 Oct 2004 10:16:37 GMT
Server: Apache/1.2.6 Red Hat
Last-Modified: Sat, 23 Jan 1999 15:23:35 GMT
ETag: „d908a-65-36a9e977“
Content-Length: 1628
Accept-Ranges:bytes
Content-Type: text/html
Age: 0
x-Cache: MISS from www.xyz.de
Proxy-Connection: keep-alive
Persistente Verbindungen –
Request Pipelining
GET / HTTP/1.1
host: inf.fu-berlin.de
connection:keep-alive
GET /images/homepage.gif HTTP/1.1
host: inf.fu-berlin.de
connection:keep-alive
…
GET /cgi-bin/people.gif HTTP/1.1
host: inf.fu-berlin.de
HTTP/1.1 200 OK
connection:close
HTTP/1.1 200 OK
Header Field connection
Werte: keep-alive, close
HTTP/1.1 200 OK
Date: Tue, 26 Oct 2004 16:56:37 GMT
Server: Apache/1.2.1
Keep-Alive: Timeout=10, max=98
Connection: Keep-Alive
Content-Type: Text/html
<html>...
HTTP/1.1 Authentication
 Digest Access Authentication neben Basic
Authentication
 Ablauf
 Username und Passwort werden MD5 kodiert …und vom Server
geprüft (keine Übermittlung des Rohpasswortes)
 OK oder Antwort mit Status-Code: 401 Unauthorized und Header
WWW-Authenticate: Digest realm=„...“, ...
 Benutzer wird vom Browser nach Passwort gefragt
 Anfrage der Ressource mit zusätzlichem Header
 Authorization: Digest realm=„...“, username=„...“
...
Web Server Survey
http://news.netcraft.com/archives/web_server_survey.html, October 2006
Dynamische Web-Anwendungen
(Applikationslogik und Datenbankzugriff)


… mehr als die Rückgabe statischer Inhalte (HTML, GIF, AVI, …)
Zwei Arten:
 Client-seitige Integration = Code beim Client und DB-Zugriff vom Browser mit
Mitteln des WWW, z.B. ActiveX, Applets
 Server-seitige Integration = HTML-Generierung

Kombination ist denkbar und sinnvoll;
Fokus: Serverseitige Ansätze
HTTPServer
Client
HTML
HTML
Internet
HTML
link
Datenbank
Serverseitige Ansätze - Übersicht
 (über die Generierung statischer HTML-Seiten hinaus)
 CGI - Common Gateway Interface
 Neuere Web Server APIs (z. B. Servlets)
 Server-seitige Skripte (z.B. JSPs)
 …
Common Gateway Interface (CGI)
Klient
(WWW-Browser)
get /cgi-bin/uptime.pl HTTP/1.0
WWW
Server
Content-type:
text/plain
9:36 am up 54 days,
• Server stellt fest: Anfrage bezieht sich auf
Programm/Skript (kein Dokument)
• Server startet das Programm/Skript und übergibt
etwaige Argumente (z. B. aus HTML-Formular)
• Server gibt Output des Programms/Skripts
(HTTP + HTML) über Web Server zurück an den Client
• Im Falle eines Fehlers übergibt der Server eine
Fehlermeldung an den Client zurück
uptime.pl
CGI
Script
CGI-Skripts
Beispiel (In Perl):
#!/usr/local/bin/perl
$UPTIME = /usr/bin/uptime ;
print “Content-type: text/html\n\n”;
print “<HTML>\n\<BODY>\n“;
Uptime-Kommando:
9:36 am up 54 days, 1:46
HTML-Output:
Content-type: text/html
if (-x $UPTIME) {
print `$UPTIME`;
} else {
print “No uptime command.\n”;
}
print “</BODY>\n</HTML>\n“;
<HTML>
<BODY>
9:36 am up 54 days, 1:46
</ BODY>
</HTML>
WWW-Formulare
<FORM method=GET action=http://www.google.com/custom>
<INPUT TYPE=text name=q size=31 maxlength=255 value="">
<INPUT type=submit name=sa VALUE="Search">
</form>
Umgebungsvariablen I
 Server stellt dem Programm Environment-Variablen zur
Verfügung!
 Diese enthalten Variablen, die per GET übertragen worden
sind und Systemvariablen







SERVER_NAME
SERVER_PROTOCOL
REQUEST_METHOD
PATH_INFO
SCRIPT_NAME
QUERY_STRING
REMOTE_ADDR
Hostname/DNS/IP
Name + Revision
POST, GET
Pfad des Programms
Pfad + Name
mit GET übertragene Daten
IP des anfragenden Hostes
Umgebungsvariablen II






CONTENT_TYPE
CONTENT_LENGTH
HTTP_ACCEPT
HTTP_USER_AGENT
HTTP_COOKIE
HTTP_REFERRER
bereitgestellte Daten
Länge der Daten
MIME-Typen des Browsers
Kennung des Browser
Cookie-Daten, falls versandt
letzte Adresse, von der der Browser kam
 Zugriff auf Umgebungsvariablen aus Programmen:
 C or C++: #include <stdlib.h>
char *query = getenv(„QUERY_STRING");
 Perl:
$query = $ENV{‚QUERY_STRING„};
 C shell:
set QUERY = $QUERY_STRING
Übergabe über Standard-Input
 Server prüft, ob Informationen an Header angehängt und
legt gefundene Informationen auf Standard-Input des CGIProgramms
 Server setzt CONTENT_LENGTH und CONTENT_TYPE
 Beispiel: x=4&y=2 mit POST übertragen
x=4&y=2 auf Standard-Input des Programms
 CONTENT_LENGTH=7
 CONTENT_TYPE= application/x-www-form-urlencoded
 Beispiel: Perl-Anweisung zum Auslesen der Daten
 read(STDIN, my $Daten, $ENV{CONTENT_LENGTH});
CGI-Datenbankabfrage
Betätigung Submit-Button
<FORM METHOD="POST"
ACTION="http://www.xyz.de/
cgi-bin/my-form">
client
Aufruf des Skriptes
mit Parametern
Initialisierung bei
jedem Aufruf
HTTPServer
Aufbau der DB
Verbindung bei
jedem Aufruf
Datenbank
CGI-Skript
Verbindungsaufbau
Anfrage
SQL Anfrage
Antwort
Ergebnis
HTTP Server
antwortet
Skript übermittelt
HTML und beendet
sich
Skript generiert
HTML
Skript stellt Anfrage
an DB
Zustandsproblematik bei HTTP, CGI
• Durch den wiederholten
Verbindungsaufbau (Start ) kann
der Server (das Programm) den
Client nicht “wieder erkennen”
• Typisches Beispiel: Online-Shop:
Virtueller Einkaufswagen,
Kunden-ID
xxxx
Name:
ID
457
ID
457
Anonymer Anwender
(Allgemein zugängliche
Information)
Identifikation
(Eingabe von Name
und Kennwort)
Identifizierter Anwender:
Referenz muß zwischen
den einzelnen Verbindungen
übergeben werden.
z.B. in Form einer ID
Zustandsmanagement
URL-Encoding: ID als Argument eines Formular vorweg nehmen:
<FORM ACTION=“http://csw/cgi-bin/states?ID=451” METHOD=POST>
Alternativ: ID als unsichtbares Feld einfügen:
<INPUT TYPE=“HIDDEN” NAME=“ID” VALUE=“451”>
Die meisten Browser erkennen Cookies, im Browser aufbewahrt
& mit nächstem Request wieder an den Server zurückgeschickt
werden:
Content-type: text/html
Set-Cookie: ID=451
Bewertung von CGI
 Vorteile
 Beliebige Programme können integriert werden
(sprachunabhängig)
 Sicherheit durch eigenen Prozess (im User Space)
 Bei allen gängigen Webservern implementiert
 Nachteile





Ein Prozess pro Anfrage
Für jede DB-Anfrage Verbindung aufbauen und trennen(!)
Keine Speicherung des Zustands durch den HTTP Server
Keine Trennung von Präsentation und Anwendungslogik
Keine Lastverteilung zugunsten des Servers /es sei denn, die
Applikation läuft auf separatem Server (Aufrufproblematik!)
Neuere Web-Server APIs
 Entwickelt um Nachteile der CGI-Skripte zu überwinden
 Werden in die Serverumgebung (Context) geladen
 Müssen meist nur einmal geladen werden
 Werden in Threads statt Prozessen ausgeführt
 Sind in der Lage, Zustände zu speichern
 Bekannte Vertreter





Java Servlets (Java Servlet API, Sun)
Apache API (MODPERL, MODPHP, …)
NSAPI (Netscape)
ISAPI
…
API-basierte Ansätze
Betätigung Submit-Button
<FORM METHOD="POST"
ACTION="http://www.xyz.de/
cgi-bin/my-form">
client
Aufruf des Programms,
Parameterübergabe
Initialisierung bei ersten
Aufruf (einmalig)
Verbindungsaufbau zur
DB beim ersten Aufruf
(einmalig)
HTTPServer
Datenbank
Verbindungsaufbau
Anfrage
Programm
SQL Anfragen
Antwort
Ergebnisse
Zustand
Beliebig viele
SQL Anfragen
HTML-Rückgabe
HTML-Generierung
Server-seitiges Java => Servlets
 Einfaches Web-Server API für Java Anwendungen
 Plattformunabhängigkeit und leichte Portierbarkeit
 Servlet bleibt geladen, nachdem eine Anfrage abgearbeitet wurde;
CGI-Programm muss stets neu geladen werden


Servlet Spezifikation durch Sun, aktuelle Version: 2.5
Implementierung durch verschiedene Servletengines





Tomcat von Apache
JRun von Macromedia (Allaire)
IBM WebSphere
Oracle Application Server
…
Servlet Servlet
Client
Web
Server
Servlet
Engine
Multithreading
Kernzprozess
Request für Servlet1
JVM
thread
Servlet1
Request für Servlet2
thread
Servlet2
Request für Servlet1
thread
Entwicklung: Klasse HttpServlet
(Package: javax.servlet.http)
 Bietet Grundfunktionalitäten, um auf HTTP-Anfragen zu
reagieren
 Dabei muß eine der folgenden Methoden überschrieben
werden:
 doGet, wenn das Servlet HTTP GET Anforderungen
entgegennehmen kann.
 doPost, für HTTP POST Anforderungen
 doPut, für HTTP PUT Anforderungen
 doDelete, für HTTP DELETE Anforderungen
 init and destroy, für Ressourcen, die für den Lebenzyklus eines
Servlets gehalten werden sollen
Übersicht
Web
GET request Server
HttpServlet
Unterklasse
doGet()
response
service()
POST request
doPost()
response
Java Servlets - Methoden

void init()
Initialisiere das Servlet (z.B. setzte Parameter, instanziere Klassen oder
öffne Datenbankverbindung)

void doGet(HttpServletRequest, HttpServletResponse)
durch Anfrage vom Typ GET aufgreufen, enthält Funktionalität des Dienstes

void doPost(HttpServletRequest, HttpServletResponse)
durch Anfrage vom Typ POST aufgerufen, enthält Funktionalität des Dienstes

void destroy()
Entfernt Servletinstanz vom Speicher (z.B. schließe DB Verbindung)
Beispiel 1/3
<html>
<body>
<form action="RequestParamExample" method=POST>
Vorname:
<input type=text size=20 name=firstname>
<br>
Nachname:
<input type=text size=20 name=lastname>
<br>
<input type=submit>
</form>
</body>
</html>
Beispiel liest Input
eines Web-Formulars
und gibt diesen im
Web wieder aus
Beispiel 2/3
import
import
import
import
javax.servlet.*;
javax.servlet.http.*;
java.io.IOException;
java.io.PrintWriter;
Objekt zum Handling&
Infos bzgl. Request
public class CSWServlet extends HttpServlet {
protected void doPost(HttpServletRequest request,
HttpServletResponse response) throws
ServletException, IOException {
// Auslesen der Request-Parameter
String firstName = request.getParameter("firstname");
String lastName = request.getParameter("lastname");
Objekt zum Handling&
Infos bzgl. Response
Beispiel 3/3
// ContentType setzen und Ausgabe-Stream anfordern
response.setContentType("text/html");
PrintWriter out = response.getWriter();
// Ausgabe
out.write("<html>\r\n<head><title>Servlet Beispiel Ausgabe</title><head>");
out.write("<body>\r\n<font face=\"Arial\">\r\n");
out.write("Vorname: " + firstName + "<br>\r\n");
out.write("Nachname: " + lastName + "<br>\r\n");
out.write("</font>\r\n</body></html>");
} // doPost
} // CSWServlet
HttpServletRequest
 Beinhaltet Information vom Client zum Servlet
 Wichtige Methoden:
 Enumeration getParameterNames()
 Liefert eine Liste aller Namen der übergebenen
Parameter
 String[] getParameterValues(java.lang.String name)
 Liefert eine String-Array mit allen übergebenen
Parameter-Werten
 ServletInputStream getInputStream()
 Liefert einen ServletInputStream aus dem binäre
Daten vom Client gelesen werden können
HttpServletResponse
 Beinhaltet Information vom Servlet zum Client
 Wichtige Methoden
 void setContentType(java.lang.String type)
 Setzt den Content-Typ der Antwort (z.B. text/html).
 PrintWriter getWriter()
 Liefert eine PrintWriter-Objekt um Daten an den
Client zu schicken
 ServletOutputStream getOutputStream()
 Liefert einen ServletOutputStream um binäre Daten
an den Client zu schicken
Zustandsmanagement:
Session Interfaces
 javax.servlet.http.Cookie
 Explizites Setzen von Cookies
 javax.servlet.http.HttpSession
 Einfacher und mächtiger
 Cookies/URL Rewriting transparent für
Entwickler
 Objekte werden „in Sessions“ gespeichert
HttpSession
Beispiel: HttpSession
...
Session session = request.getSession();
ShoppingCart cart = session.getAttribute(“Einkaufswagen“);
if (cart == null) {
cart = new ShoppingCart();
session.setAttribute(“Einkaufswagen“, cart);
…
}
if (request.getParameter(“add_item“) != null) {
String itemId = request.getParameter(“item_id“);
Item item = catalogue.getItem(itemId);
cart.addItem(item);
...
}
...
RequestDispatcher
Eingabe.html
post
Servlet zur
Prüfung der Eingabe
forward
include
Eingabe.html
post
KomponentenServlet
If(x<0)
include
If (x>0)
include
DatenbankServlet
Header.html
Inhalt1.html
Inhalt2.html
RequestDispatcher - Syntax
 forward:
...
RequestDispatcher dispatcher =
request.getRequestDispatcher(“PostProcessingServlet“);
dispatcher.forward(request, response);
...
 include:
...
RequestDispatcher dispatcher =
request.getRequestDispatcher(“header.html“);
dispatcher.include(request, response);
out.write(“Der eigentliche Inhalt ...“);
...
Servlet Filter
 Filter können Requests oder Responses ändern bevor sie
eine Ressource erreichen, bzw. nachdem sie von dieser
verarbeitet wurden
 Sequenz der Filter kann in Deployment Descriptor definiert werden
 Anwendungen




Prüfen eines HTTP Request
Authentifizierung und Autorisierung
Auditing und Logging
…
request
response
Filter 1
Filter 2
Ressource:
HTML
Servlet
JSP
Lebenszyklus von Servlets
Einfaches Zähler Beispiel
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Counter extends HttpServlet
{
int count = 0;
public void doGet(HttpServletRequest req, HttpServletResponse res) throws
ServletException, IOException
{
res.setContentType(“text/html”);
PrintWriter out = res.getWriter();
count++;
out.println(“This servlet has been accessed “ + count + “ times
since loading”);
}
}
Problem
 Die Servlet Engine lädt eine Instanz, die mehrere
auch gleichzeitige Anfragen bearbeitet
 Thread Sicherheit?
 Beispiel:
count++
//thread 1 - count=1
count++
//thread 2 - count=2
out.println(count)
//thread 1 -> 2
out.println(count)
//thread 2 -> 2
Lösungsansätze
 Schutz des Schreibzugriffs auf nicht-lokale Variablen durch
Verwendung von “synchronize”
 Synchronisieren der doGet() Methode
public synchronized void doGet
(HttpServletRequest req, HttpServletResponse res)
 Servlet kann nur mehr einen GET Request gleichzeitig
bearbeiten
 Synchronisieren kritischer Bereiche
PrintWriter out = res.getWriter();
synchronized(this)
{
count++;
out.println(“This servlet has been accessed “ + count + “ times since
loading”);
}
Single-Thread Model
 Das Single-Thread Model garantiert im Gegensatz dazu,
dass keine 2 Threades gleichzeitig die service()-Methode
einer Instanz aufrufen
 Üblicherweise laufen allerdings mehrere Instanzen
public class SingleThreadServlet
extends HttpServlet
implements SingleThreadServlet {
…
}
Servlet Engines

Servlet-Engines sind im wesentlichen eine JVM als Laufzeitumgebung für
Servlets mit spezifischen Methoden zur Abwicklung des Lebenszyklus

Web-Server mit integrierter Servlet-Engine:
 Bsp.: Java WebServer von Sun
 WebServer in Java geschrieben, Class-Dateien der Servlet-Engine zu denen des
WebServers hinzugefügt.

Separate Servlet-Engine
 verlangen eine getrennte Laufzeit-Umgebung für die Servlet-Engine und ein Web
Server Plug-In zur Integration der Java-Umgebung.
 Das Plug-In hat u.a. die Aufgabe, die Kommunikation zwischen Web Server und
Servlet-Engine zu vermitteln.
 Tomcat
 vollwertiger Web-Server, oft eingesetzt als Module des Apache Web Server
 Jakarta-Projekt, wird unter Apache-Software-Lizenz entwickelt
 http://jakarta.apache.org (Servlets 2.2, JSP 1.1)
Java Servlets - Deployment
 Ein Servlet muss in einem Servlet Container deployed
werden
 Direkt als ausgepackte Verzeichnisstruktur oder
 als Web Archive (.war)
 Verzeichnisstruktur von Webanwendungen ist durch die Java
Servlet Spezifikation spezifiziert
 Ein Webarchive kann mit dem Tool “jar” erzeugt werden
 Struktur aller Dateien muss dieser Spezifikation entsprechen
 jar –cf meinServlet.war WEB-INF *.html *.css
 Instruktionen zum Deployment finden sich in der Datei
web.xml, dem Deployment Descriptor
Java Servlets - Deployment
Verzeichnisstruktur einer Webapplikation:
 nameOfApplication/
 Zusätzliche Dateien (z.B. HTML, CSS, GIF, JSP Dateien), können in
Subverzeichnissen sein
 nameOfApplication/WEB-INF/
 Deployment Descriptor web.xml
 nameOfApplication/WEB-INF/classes/
 .class – Datei des Servlets and alle anderen Java Klassen.
 Unterverzeichnisse in /classes – Verzeichnis entspricht Paketstruktur
der Implementierung
 nameOfApplication/WEB-INF/lib/
 .jar - Archive
Java Web Application:
Web Application Archive (WAR)
 Eine Server-seitige Java Applikation als eine
Einheit installierbar
 Servlets und JSP Seiten
 HTML Dokumente und Bilder
 Andere Web Ressourcen
 Erweiterung des JAR Dateiformates
 Einführung in Servlet Spezifikation v2.2
 Multi-platform, multi-vendor
WAR (Web Application Archive)
app.war
JSP pages, HTML documents, image files
Content
directories
JSP pages, HTML documents, image files
web.xml
WEB-INF
classes
Class files
beans
Package
directories
lib
JAR files
tlds
TLD files
Servlet
\WEB-INF\classes
Aufruf: http://host/application/servlet/S
Servlet S im Package csw:
\WEB-INF\classes\csw
Aufruf: http://host/application/servlet/csw.S
Bibliotheken:
\WEB-INF\lib soll z.B. ein Servlet oder
eine JSP mit Treiber aus der
Bibliothek mylib.jar arbeiten, dann
JAR-Archiv ins lib-Verzeichnis kopieren
Class files
Konfigurationsinfomation:
\WEB-INF\web.xml (Kontextparameter
der Servlets, Time-Out für Sessions,
Zugriffsrechte auf Dateien)
Tag Library Descriptions zur Definition eigener
Tags (JSP)
Deployment von WAR-Dateien
 Wurzelverzeichnis zippen und umbenennen
(.war)
 WAR Datei in Webapps Dir. von z.B. Tomcat
kopieren
 Tomcat entpackt die Datei beim Starten in ein
Verzeichnis mit gleichem Namen
 Der Tomcat Manager erlaubt Deployment einer
Web Applikation ohne Neustart (Hot-Deployment)
 Ebenso kann ein kompiliertes Servlet einfach im
entsprechenden Verzeichnis ersetzt werden
Deployment Descriptor
 Deployment Descriptor WEB-INF/web.xml
 <web-app> enthält folgende Information:









Application configuration
Servlet configuration
Session configuration
MIME types
Default pages
Custom tag libraries
External resources
Security
J2EE configuration
Java Servlets - Deployment
Der Deployment-Descriptor web.xml:
 Wird benötigt:
 Registrierung der Servlet Klassen
 Abbildung der Dienst URL auf Servletklassen (URL
Mapping)
 Optional:





Initialisierung der Parameter
Timeouts
Start- und Fehlerseiten
Sicherheitskonfiguration
…
web.xml Beispiel
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"
"http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app>
<display-name>Servlet Beispiele</display-name>
<description>CSW Beispiele für Servlets und JSPs</description>
<servlet>
<servlet-name>Hello</servlet-name>
<description>Hello World Servlet</description>
<servlet-class>HelloWorld</servlet-class>
<load-on-startup>5</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Hello</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>30</session-timeout>
</session-config>
</web-app>
Allgemeine Information
über die Applikation
Definiert den Namen des
Servlets und ordnet ihn
einer Klasse zu
Ordnet den Namen einer
URL zu
<!-- 30 minutes -->
Entwicklungsumgebung Eclipse
 Local Tomcat: Start/Stop/Restart via Eclipse Plug-In:
 Administration of local Tomcat context:
http://localhost/manger/html/
User: e.g. tomcat Pwd: e.g. tomcat
Bewertung von Servlets
 Vorteile
 Höhere Leistungsfähigkeit
 Programmierkomfort
 Z.B. HttpSession -> Zustandsproblem
 Geringerer Ressourcenverbrauch
 Nachteile
 Nur Java
 Keine Trennung von Präsentation und
Anwendungslogik
Literatur
 Folien, Web
 HTTP:
 http://www.w3.org/Protocols/
 Servlet
 http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
 http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial/
 http://www.galileocomputing.de/openbook/javainsel5/, Chapter 17
 Servlet und JSP Buch:
 Hall, M.: Core Servlets and Java Server Pages; Sun Microsystems
Press/Prentice Hall PTR, 2000.
 Übersichtsartikel:
 Turau, V.: Techniken zur Realisierung Web-basierter Anwendungen, Informatik
Spektrum, 22 (1999) 1, S. 3-12.