Terminübersicht 1) Termin: Einführung Java-Netzwerk Programmierung (mit Übungsaufgaben) 2) Termin: Einführung Java-Netzwerk Programmierung II. Einführung HTTP-Protokoll 3) Termin: Erläuterung der Aufgabenstellung, Definition der Aufgabe Anhand von Use-Cases In Gruppen 4) Termin: Entwurf (Selbständiger Entwurf der Gruppen), Falls nötig kurze Auffrischung UML,Aktivitätsdiagram, Klassendiagram 5) Termin: Implementierung 6) Termin: Implementierung / Abnahme 7) Termin: Puffer

Packages Def: Ein Package ist eine logische Sammlung von Klassen und Interfaces. Ein Package stellt einen Namensraum und somit auch eine Zugriffsschutz zur Verfügung. Das verwenden von Packages birgt folgende Vorteile: Zusammenfassung von miteinander in Beziehung stehenden Klassen. Klassennamen geraden nicht in Konflikt mit Klassennamen in anderen Packages Zugrifsschutzmechanismus für Klassen im selben Package. Auffinden von Packages: Packagename wir als Anhang an Klassenpfad interpretiert.

Javadoc Tool zur automatischen Dokumentation der Klassen Beispiel: Klassendokumentation /* * @(#)MailStatusEvent.java 0.1 99/10/07 * Copyright (c) 1999 Michael Kleeberg */ Beispiel: Methodendokumentation /** * Konstruktor für ein MailStatusEvent * @param source Die Quelle des Events. * @param message Textuelle Beschreibung des Events * @return true wenn erfogreich, false wenn nicht *@exception MessagingException wird bei Problemen geworfen * @see javax.mail.MessagingException. Beispielaufruf: java –d c:\test *.java Weitere Informationen: \jdk\docs\tooldocs

Netzwerkprogrammierung mit Java Ein Netzwerk ist eine Ansammlung von Rechnern welche zum Datenaustausch miteinander verbunden sind (auf welche Art auch immer). Die Geräte welche ein Netzwerk ausmachen werden als sogenannte „Nodes“ bezeichnet. Rechner bezeichnet man in einem Netzwerk üblicherweise als „Hosts“. In einem Netzwerk ist jeder „Node“ zur eindeutigen Adressierung mit einer Adresse versehen. Diese nimmt bei den unterschiedlichen Netzwerktypen unterschiedliche Formen an (z.B. AppleTalk-Adressen, Inet-Adressen usw.) Java bietet mit seinem Objektorientierten Ansatz eine sehr komfortable Umgebung um Programme im Netzwerkumfeld zu schreiben.

Physical Layer (LocalTalk, Ethernet etc.) Netzwerkmodell Folgendes Netzwerkmodell stellt vereinfacht die Netzwerkschichten wie Sie z.B. im Internet gebräuchlich sind dar. Application-Layer Protokolle der Anwendungsschicht (HTTP, POP,etc.) Transport-Layer Protokolle der Transportschicht (TCP,UDP) Internet-Layer Protokolle der Internetschicht (IP) Application Layer Application Layer Transport Layer Transport Layer Internet Layer Internet Layer Physical Layer (LocalTalk, Ethernet etc.)

Ports Da nicht nur eine eindeutige Zuordnung bzw. Adressierung unter verschiedenen Rechnern sonder auch unter verschiedenen Anwendungen nötig ist wurde das Konzept der „Ports“ eingeführt. „Ports“ erlauben dem Netzwerk eine Netzwerkanwendung auf einem Host gezielt zu Adresieren. Adresse Name IP-Adresse Port

Client-Server Server Client Unter einer Client Server Architektur wird eine Softwarearchitektur verstanden bei der ein Programm (Server) auf einem Rechner Dienste für vileandere Programme (Clients) in Netzwerk bereitstellt. Beispiele hierfür wären HTTP-Server, Mail-Server, FTP-Server usw. Server Client Verbindung aufnehmen Port Daten austauschen I/O Stream I/O Stream I/O Stream andere Clients

Peer-to-Peer Bei sogenannten Peer-to-Peer Anwendungen gibt es keinen Server der Dienste für andere Anwendungen im Netz bereitstellt sondern 2 (oder mehr)Anwendungen kommunizieren gleichberechtigt über das Netz untereinander. Verbindung aufnehmen Port Port Daten austauschen I/O Stream I/O Stream

Wichtigsten Netzwerkklassen (1) Verwendung InetAdress Zum bearbeiten bzw. verwenden von Internetadressen. URL Zum bearbeiten bzw. verwenden von URL-Adressen URLEncoder Zum codieren von URLs (Sonderzeichenbehandlung) Socket Klasse zur Socketbasierten Kommunikation (Client) ServerSocket Klasse zur Socketbasierten Kommunikation (Server)

InetAdress Die Klasse java.net.InetAddress dient zur Darstellung und zur Bearbeitung bzw. Auflösung von IP-Adressen. InetAdress Objekte erzeugen public static InetAdress getByName(String hostname); public static InetAdress[] getAllByName(String hostname); Public static InetAdress getLocalHost(); Hostname ermitteln public String[] getHostName(); Adresse ermitteln public byte[] getAdress(); public String getHostAdress();

Aufgabe Schreiben Sie ein Programm „nslookup“ welches IP-Adressen in Hostnamen auflößt bzw. Hostnamen in IP-Adressen auflöst. Ermöglichen Sie dazu die Eingabe von Hostnamen bzw. IP-Adressen über die Tastatur oder über die Parameterübergabe der Kommandozeile. Beispiel: Kommandozeile nslookup www.seeburger.de Server: www.seeburger.de Adress: 212.227.174.147 Eingabe nslookup www.seeburger.de TIP: Benutzen Sie BufferedReader=  new BufferedReader(new InputStreamReader(System.in)) zum einlesen.

URL Die Klasse java.net.URL stellt eine Hilfsklasse dar die den Umgang mit URLs stark erleichtert. Erzeugen von URL-Objekten public URL(String url); public URL(String prot,String host, String file); public URL(String prot,String host,int port,String file); Zerlegen von URLs public String getProtocol(); public String get Host(); public String getFile(); public int getPort(); public String getRef(); Lesen von Daten auf einer URL public final InputStream openStream(); public URLConnection openConnection(); public final Object getContent();

URL Encoder Die Klasse java.net.URLEncoder dient zur Kodierung von „Sonderzeichen“ gemäß den Regeln einer URL. Beispiele: Text.mit.Punkt Kodiert Text%2emit%2ePunkt Text mit Spaces Kodiert Text+mit+Spaces usw. Zu diesem Zweck hat die Klasse eine einzige Methode public static URLEncoder.encode(String URL); Welche diese Aufgabe erledigt.

Aufgabe Schreiben Sie ein Programm welches einen „Offline Reader“ darstellt. Das Programm soll eine Liste von HTTP-URLs bekommen welche dann heruntergeladen und abgespeichert werden sollen. Zusatzaufgabe: Erweitern Sie das Programm so das a) Links in Seiten erkannt und bis zu einer vorgegebenen Tiefe zum runterladen verfolgt werden. b) Links relativ zum neuen Speicherplatz angepasst werden.

Sockets Ein Socket ist der Endpunkt einer bidirektionalen Kommunikationsverbindung zwischen 2 Programmen in einem Netzwerk. Ein Socket ist ist immer einem Port zugeordnet (auf einen Port gebunden) so das die TCP Schicht die Anwendung Adressieren kann. Man unterscheidet zwischen Sockets für Serveranwendungen, welche in Java durch die Klasse ServerSocket abgebildet werden, und Sockets für Clientanwendungen welche durch die Klasse Socket abgebildet werden.

Kommunikation über Sockets Der Client nimmt zu einer Serveranwendung welcher einbestimmter Port zugeordnet ist auf einen durch die IP Adresse bestimmten Host Verbindung auf. Der Server nimmt die Verbindung auf dem wohlbekannten Port entgegen und weißt dieser Verbindung dann einen neuen Port zu. Die Kommunikation auf diesem neuen Port wird dann üblicherweise in einem eigenen Thread abgewickelt. Auf diese Art und weiße bleibt der ursprüngliche Port frei so das auf Ihm weitere Verbindungen angenommen werden können Telnet.

Sockets für Clients Beispiel zum Erzeugen eines Clientsockets In Java werden die Sockets auf Clientseite durch die Klasse java.net.Socket abgebildet. Beispiel zum Erzeugen eines Clientsockets Socket aSocket = new Socket(„host“, 8); Beispiele für wichtige Methoden:

import java.io.*; import java.net.*; public class EchoClient { public static void main(String[] args) throws IOException { Socket echoSocket = null; PrintWriter out = null; BufferedReader in = null; try { echoSocket = new Socket("kleeberg", 7); out = new PrintWriter(echoSocket.getOutputStream(), true); in = new BufferedReader(new InputStreamReader( echoSocket.getInputStream())); } catch (UnknownHostException e) { System.out.println("Host not found !"); System.exit(1); } catch (IOException e) { System.out.println("Couldnt get IO-Streams"); System.exit(1); } BufferedReader stdIn = new BufferedReader( new InputStreamReader(System.in)); String userInput; userInput = stdIn.readLine(); out.println(userInput); System.out.println("echo: " + in.readLine()); out.close(); in.close(); stdIn.close(); echoSocket.close(); }

Aufgabe Schreiben Sie einen einfachen Portscanner. Ein Portscanner versucht auf einem gegebenen Host zu ermitteln welche Ports von Diensten belegt sind. Ermitteln Sie dieses indem Sie versuchen sich mittels Sockets auf den jeweiligen Port zu verbinden. Geben Sie das Ergebniss auf dem Bildschirm aus. Parallelisieren Sie das ganze in dem Sie Threads benutzen. Das Programm soll als Argumente den Hostnamen, den Grad der Parallelisierung und das zu scannende Portintervall übergeben bekommen. Aufruf: portscan hostname, numberOfThreads, startPort, endPort Tips: Schreiben Sie 2 Klassen. A) Die Hauptklasse Portscan welche Parameter auswertet, die einzelnen Scannthreads (Instanzen von CheckPort) startet, darauf achtet das die richtigen Ports gescannt werden , sich um die Ausgabe des Ergebnisses kümmert, und darauf achtet das die maximale Anzahl von parallelen Threads nicht überschritten wird. B) Die von Thread abgeleitete Klasse CheckPort welche einen gegeben Port auf einen Dienst überprüft (versucht sich zu verbinden)

Sockets für Server handler.start(); Beispiel zum Erzeugen In Java werden die Sockets auf Clientseite durch die Klasse java.net.Socket abgebildet. Beispiel zum Erzeugen eines Serversockets ServerSocket sSocket = new ServerSocket (1000); Beispiel eines typischen Konstrukts zum warten auf eine Verbindung und das starten der Verarbeitung in eigenen Threads. ThreadClass handler; while(true){ handler = new ThreadClass (theSocket.accept()); handler.start(); } Beispiele für wichtige Methoden:

import java.io.*; import java.net.*; public class EchoServer { public static void main(String[] args) throws IOException { ServerSocket serverSocket = null; PrintWriter out = null; BufferedReader in = null; try { serverSocket = new ServerSocket(7); } catch (IOException e) { System.out.println("Could not bind to port: 7"); System.exit(-1); } try{ Socket echoSocket = serverSocket.accept(); out = new PrintWriter(echoSocket.getOutputStream(), true); in = new BufferedReader(new InputStreamReader( echoSocket.getInputStream())); BufferedReader stdIn = new BufferedReader( new InputStreamReader(System.in)); String userInput = in.readLine(); out.write(userInput); out.close(); in.close(); stdIn.close(); echoSocket.close(); }catch (IOException e) { System.out.println("IO-Exception occured"); System.exit(1);

Aufgabe Time Server nach RFC 868 This RFC specifies a standard for the ARPA Internet community. Hosts on the ARPA Internet that choose to implement a Time Protocol are expected to adopt and implement this standard. This protocol provides a site-independent, machine readable date and time. The Time service sends back to the originating source the time in seconds since midnight on January first 1900. One motivation arises from the fact that not all systems have a date/time clock, and all are subject to occasional human or machine error. The use of time-servers makes it possible to quickly confirm or correct a system's idea of the time, by making a brief poll of several independent sites on the network. This protocol may be used either above the Transmission Control Protocol (TCP) or above the User Datagram Protocol (UDP). When used via TCP the time service works as follows: S: Listen on port 37 (45 octal). U: Connect to port 37. S: Send the time as a 32 bit binary number. U: Receive the time. U: Close the connection. S: Close the connection. The server listens for a connection on port 37. When the connection is established, the server returns a 32-bit time value and closes the connection. If the server is unable to determine the time at its site, it should either refuse the connection or close it without sending anything. The time is the number of seconds since 00:00 (midnight) 1 January 1900 GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this base will serve until the year 2036. For example: 2,208,988,800 corresponds to 00:00 1 Jan 1970 GMT, 2,398,291,200 corresponds to 00:00 1 Jan 1976 GMT 2,524,521,600 corresponds to 00:00 1 Jan 1980 GMT

Tool zum Debugen: Tunneler Da es zum „debuging“ bei Textprotokollen über Socket Verbindungen sehr nützlich ist zu sehen was an Protokollverkehr über die Sockets geht empfiehlt es sich hier als Tool einen Tunnel dazwischen zu schalten welcher den Datenaustausch der auf dem Socket stattfindet ausgibt. Eines dieser Tools (tcpmon) ist im Apache AXIS-Toolkit enthalten. Download: www.apache.org/dyn/closer.cgi/ws/axis/1_4/ Dokumentation: ws.apache.org/axis/java/user- guide.html#AppendixUsingTheAxisTCPMonitorTcpmon Installation: a) entpacken b) CLASSPATH muss axis.jar beinhalten c) Starten: java org.apache.axis.utils.tcpmon [listenPort targetHost targetPort] Localhost Tunnelhost Tunnel S O C K E T S O C K E T APP. S O C K E T APP. Server Socket auf listenport Client Socket auf tunnelport Server Socket auf tunnelport Ausgabe

Grundlagen HTTP Was ist HTTP ? HTTP steht für Hypertext Transfer Protocol und wird im WWW als bevorzugtes Protokoll eingesetzt um Ressourcen verschiedenen Types zu transportieren (HTML-Files, Image- Files, Ergebniss einer Query ...usw). HTTP funktioniert üblicherweise über TCP/IP Sockets wobei oft Port 80 als Standardport für HTTP-Server verwendet wird. http 1.0 und der Nachfolger HTTP 1.1 sind verbreitet. Was ist eine Ressource ? In der Sprachregelung des Internet werden alle Daten (Informationen) die mittels einer URL addresierbar sind als Ressourcen bezeichnet. Ressourcen können z.B. Dateien (z.B. HTML Files) oder auch dynamisch generierte Daten (z.B. Ergebnisse von CGI Skripten) sein.

Grundlagen HTTP Ablauf einer HTTP-Transaktion HTTP ist ein zustandsloses Protokoll welches folgendem Ablauf genügt: HTTP-Server HTTP-Client Öffnet Verbindung Request Fordert Ressource an Nimmt Request an und beschafft die Ressource Response Liefert Ressource zurück Schließt Verbindung t t

Grundlagen HTTP Struktur und Aufbau eines HTTP- Request/Response Der prinzipielle Aufbau eines HTTP-Requestes oder Responses sieht wie folgt aus: Startzeile mit Methode (CRLF) 0-n Headerzeilen (CRLF) Eine leere Zeile (CRLF) Ein optionaler Datenblock (HTML File, Binärdaten....) Beispiel: GET Request z.B. http://www.test.de/path/file.html GET /path/file.html HTTP/1.0 From: user@test.de User-Agent: Client/1.0 [blank line ] Response zum GET Request HTTP/1.0 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/html Content-Length: 1354 <html> <body> <h1>test</h1> (weiter...) </body> </html>

Grundlagen HTTP Startzeile im Request Startzeile im Response Eine Requeststartzeile besteht aus 3 Teilen welche durch Leerzeichen getrennt sind. methodename ressourcenpfad httpversion Beispiel: GET /pfad/index.html HTTP/1.0 Startzeile im Response Die Responsestartzeile, oft auch Statuszeile genannt , besteht ebenfalls aus 3 Teilen. httpversion responsecode reasontext Beispiel: HTTP/1.0 200 OK Die Statuscodes unterteilen sich in Klassen gemäß ihrer Nummerierung 1xx Information 2xx Erfolg 3xx Redirects 4xx Client Error 5xx Server Error

Grundlagen HTTP Headerzeilen Headerzeilen stellen Informationen über den Request oder Response oder die darin enthaltenen Daten zur Verfügung. Headerzeilen werden im Key:Value Form angegeben. Beispiel: User-Agent: Client/1.0 HTTP 1.0 definiert 16 optionale Header. HTTP 1.1 definiert 46 Header wobei einer nicht optional ist (Host). Für Headerzeilen gelten folgende Regeln: Sie müssen mit CRLF enden. Die Headernamen sind „case-sensitiv“, die Headerwerte nicht unbedingt Zwischen : und dem Wert dürfen beliebig viele Leerzeichen sein. Headerzeilen die mir Leerzeichen oder Tab beginnen gehören zur vorherigen Zeile.

Grundlagen HTTP Datenblock Wenn eine HTTP-Nachricht einen Datenblock enthält sind üblicherweise Headerzeilen vorhanden die diesen Datenblock beschreiben mindestens: Content-Type: (MIME Type z.B. text/html, image/gif)) Content-Length: Länge des Datenblocks in Byte.

Grundlagen HTTP Wichtige HTTP- Methoden GET Dient zum Anfordern einer Ressource Beispiel: GET /path/to/file/index.html HTTP/1.0 HEAD Dient ausschließlichen Anforderung des Response Headers Beispiel: HEAD /path/to/file/index.html HTTP/1.0 POST Die Post-Methode wird benutzt um Daten zum Server zu senden die dann z.b. von einem CGI-Skript verarbeitet werden sollen. Beispiel eines „Form“-Posts: POST /path/script.cgi HTTP/1.0 From: test.test.de User-Agent: HTTPClient/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 form=kreis&farbe=gelb (+ für Spaces)

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Clients -Host Header muss gesetzt werden. In HTTP 1.1 kann ein sogenanntes „Multihoming“ stattfinden d.h. mehrere Web-Domänen können sich hinter der selben IP verbergen womit das Problem der nicht in genügender Anzahl vorhandenen IP Adressen angegangen wird. Der Host header dient hier dann dazu die gewünschte Web-Domäne zu identifizieren. Beispiel: GET /path/file.html HTTP/1.1 Host: www.z.de [Leerzeile]

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Clients -„chunked Data“ muss verarbeitet werden können In HTTP 1.1 kann ein Server bereits mit dem versenden von Daten beginnen bevor er deren genaue Länge kennt. Um dies zu tun muss er „Chunked Data“ unterstützen. Im Falle von „Chunked Data“ ist der Header Transfer-Encoding: chunked zu setzen. Der Aufbau des Responses mit „Chunked Data“ lautet wie folgt: HTTP/1.1 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/plain Transfer-Encoding: chunked 1a; [semikolon optional, wietere keys optional] abcdefghijklmnopqrstuvwxyz 10 1234567890abcdef some-footer: some-value another-footer: another-value [Leerzeile] Header Größe in des folgenden Blocks in Hex. Daten Größe in des nächsten Blocks in Hex. Daten Abschlussmarkierung durch 0 Weiter Headerfelder

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Clients -„persistent connections“ müssen unterstützt werden Ab HTTP 1.1 können mehrere Requests durch ein und dieselbe Verbindung abgesetzt werden. In HTTP 1.1 ist dies die Voreinstellung. Soll die Verbindung von Client nicht erhalten werden muss der Header Connection: close gesetzt sein. Die Responses müssen in derselben Reihenfolge gelesen werden wie die zugehörigen Requests gesendet wurden. Es ist zu beachten das ein Server die Verbindung schließen kann bevor alle Responses gesendet werden. Es ist ratsam dies zu überwachen und unter Umständen die betreffenden Requests erneut zu senden. -„100 continue“ Response muss unterstützt werden Im Falle einer langsamen Verbindung kann ein HTTP-Server mit mittels der „100 continue“ Response anzeigen das er den Request erhalten hat und die „echte“ Response jetzt irgendwann kommt. HTTP/1.1 100 Continue HTTP/1.1 200 OK Date: Fri, 31 Dec 1999 23:59:59 GMT Content-Type: text/plain Content-Length: 42 [Leerzeile] abcdefghijklmnoprstuvwxyz1234567890abcdef Erste Response mit „100 continue“ Eigentliche Response

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Servers -Host Header wird verlangt. Der Server muß überprüfen ob der Host Header korrekt gesendet wurde und falls nicht vorhanden mit einem „400 Bad Request“ Status antworten. -Absolute URLs müssen angenommen werden. http 1.1 Server müssen auch URLs mit absoluten Pfaden annehmen und verarbeiten. Beispiel: GET http://www.somehost.com/path/file.html HTTP/1.2 -“Chunked Data“ in Requests muss verarbeitet werden können. Analog zu HTTP 1.1 konformen Clients im Response müssen auch HTTP 1.1 konforme Server „chunked Data“ im Request verarbeiten können. -“Persistend Connections“ müssen verarbeitet werden können. Ein http 1.1 konformer Server muss analog zu den Clients mehrere Requests/Responses durch eine persistente Verbindung abhandeln können. Wird dies nicht unterstützt muss der Connection: close Header vom Server gesetzt werden.

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Servers -“100 Continue“ Response muss genutzt werden. Ein HTTP 1.1 Server muss die „100 Continue“ Response benutzen wenn eine http 1.1 Request eintrifft. Nicht bei http 1.0 Requests verwenden da die Clients nichts mit anfangen könnten Beispiel: HTTP/1.1 100 Continue [blank line here] [another HTTP response will go here] . -Date Header muss unterstützt werden. Alle HTTP 1.1 konformen Server müssen den Date Header in allen Responses außer denen mit 100er Stati setzen. Dies ermöglicht die Verwendung von Cachingmechanismen im Server. Beispiel: Date: Fri, 31 Dec 1999 23:59:59 GMT

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Servers -Requests mit If-Modified-Since: oder If-Unmodified-Since: Headers müssen verarbeitet werden Um nur seit dem letzten Reques nicht geänderte Ressourcen übertragen zu müssen unterstützt HTTP 1.1 den If-Modified-Since: und If-Unodified-Since: Header. http 1.1 konforme Server müssen wenn diese Header gesendet werden dies auch unterstützen. 3 mögliche Datumsformate sind erlaubt: Beispiel: If-Modified-Since: Fri, 31 Dec 1999 23:59:59 GMT If-Modified-Since: Friday, 31-Dec-99 23:59:59 GMT If-Modified-Since: Fri Dec 31 23:59:59 1999 Der If-Unmodified-Since: header wird in Zusammenhang mit der GET-Methode benutzt. Wenn die angeforderte Ressource seit der angegebenen Zeit geändert wurde wird Sie ganz normal zurückgegeben wenn nicht wir ein "304 Not Modified" mit gesetztem Date: header gesendet. Beispiel: HTTP/1.1 304 Not Modified Date: Fri, 31 Dec 1999 23:59:59 GMT [Leerzeile] Der If-Unmodified-Since: header funktioniert analog für Ressourcen welche nicht geändert wurden, falls geändert wird ein "412 Precondition Failed" Response gesendet. Beispiel: HTTP/1.1 412 Precondition Failed [Leerzeilen]

Erweiterungen in HTTP 1.1 gegenüber HTTP 1.0 Auf Seite des Servers -Unterstützung der GET und HEAD Methoden. Ein zu HTTP 1.1 kompatibler Server muss mindestens die Methoden GET und HEAD unterstützen. POST sollte unterstützt werden muß aber nicht. Weiterhin definiert HTTP 1.1 4 weitere Methoden: Put Delete Options Trace Wird eine Methode nicht unterstützt so muss der Server mit „501 Not Implemented“ antworten. Beispiel: HTTP/1.1 501 Not Implemented [blank line here] -HTTP 1.0 Unterstützung. Ein zu HTTP 1.1 konformer Server muss alle „required“ Protokollkomponenten von HTTP 1.0 unterstützen. Unter anderem heißt das -‘Wenn die Request mit http 1.0 kommt nicht Header verlangen und kein „100 continue“ senden.

Aufgabenstellung: HTTP 1.1 Server Es soll ein rudimentärer HTTP 1.1-Server entwickelt werden welcher folgenden Anforderungen genügt: X Unterstützung der GET, HEAD, POST Methode gemäß HTTP 1.0/HTTP 1.1 X Unterstützungen von „persistenten“ Verbindungen nach HTTP 1.1 X Unterstützung der „100 continue“ nach HTTP 1.1 X Unterstützung von „Multihoming“ Unterstützung „absoluter URLs“ X Unterstützung von „If-Modified-Since“ und „If-Unmodified-Since“ Header Unterstützung von „Chunked Data“ beim Request und Response. X Unterstützung mehrerer paralleler Verbindungen Beschleunigung durch eingebauten Cachingmechanismus X Konfiguration mittel Propertiedateien. Zu liefern sind: - Programmentwurf (Use-Cases, Klassendiagramme, Aktivitätendiagramme) - Referenzimplementierung inklusive Klassendokumentation via Javadoc, kurze Benutzerdokumentation

Spezifikationen, Literatur -Netzwerkprogrammierung mit Java Java Network Programming ISBN: 188477749X TCP/IP Sockets in Java ISBN: 1558606858 -http HTTP 1.0 (RFC 1945)-- http://www.ics.uci.edu/pub/ietf/http/rfc1945.html HTTP 1.1 Latest (rev 06, 18-Nov-1998)-- http://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-rev-06.txt Verwandte RFCs: RFC 822-- structure of Internet text messages, including header fields http://www.cis.ohio-state.edu/htbin/rfc/rfc822.html RFC 2396-- definition of URL/URI syntax (replaces RFC 1738 and RFC 1808) http://www.cis.ohio-state.edu/htbin/rfc/rfc2396.html RFC 1521-- definition of MIME and of MIME types http://www.cis.ohio-state.edu/htbin/rfc/rfc1521.html