Upload
krimhilde-schnorr
View
122
Download
3
Embed Size (px)
Citation preview
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 KlassenBeispiel: 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.
Netzwerkmodell
Folgendes Netzwerkmodell stellt vereinfacht die Netzwerkschichten wie Sie z.B. im Internet gebräuchlich sind dar.
Internet-Layer
Application-Layer
Transport-Layer
Application Layer Application Layer
Transport Layer
Internet LayerInternet Layer
Transport Layer
Physical Layer (LocalTalk, Ethernet etc.)
Protokolle der Anwendungsschicht (HTTP, POP,etc.)
Protokolle der Transportschicht (TCP,UDP)
Protokolle der Internetschicht (IP)
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
Nam
e
Nam
e
Nam
e
Nam
eIP-Adresse
Port
Port
Port
Port
Client-Server
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.
PortI/O Stream
Server
Verbindung aufnehmen
Daten austauschen
Client
I/O Stream
I/O Streamandere 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.
PortI/O Stream
PortI/O Stream
Verbindung aufnehmen
Daten austauschen
Wichtigsten Netzwerkklassen (1)
Klasse 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)
InetAdressDie 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
Adresse ermitteln
public String[] getHostName();
public byte[] getAdress();
public String getHostAdress();
AufgabeSchreiben 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
Server: www.seeburger.de
Adress: 212.227.174.147
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
In Java werden die Sockets auf Clientseite durch die Klasse java.net.Socket abgebildet.
Beispiel zum Erzeugeneines Clientsockets
Beispiele für wichtige Methoden:
Socket aSocket = new Socket(„host“, 8);
Name Funktion public void close() Schließt den Socket InputStream getInputStream() Liefert einen InputStream auf den Socket OutputStream getOutputStream() Liefert einen OutputStream auf den Socket void shutdownInput() Deaktiviert die Eingabe über den Socket Void shutdownOutput() Deaktiviert die Ausgabe über den Socket.
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
In Java werden die Sockets auf Clientseite durch die Klasse java.net.Socket abgebildet.
Beispiel zum Erzeugeneines Serversockets
Beispiele für wichtige Methoden:
ServerSocket sSocket = new ServerSocket (1000);
Name Funktion Socket accept() Wartet auf eine Verbindung close() Schliest den ServerSocket int getLocalPort() Ermittelt die Portnummer des Sockets InetAddress getInetAddress() Ermittelt das zugehörige InetAddress Objekt
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();}
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 868This 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 GMT2,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]
APP.
Ausgabe
LocalhostSOCKET
SOCKET
Tunnel
APP.
Tunnelhost
SOCKET
Server Socket auf listenport
Server Socket auf tunnelport
Client Socket auf tunnelport
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:
Request
Response
t t
HTTP-Client HTTP-Server
Öffnet Verbindung
Schließt Verbindung
Fordert Ressource an Nimmt Request an und beschafft die Ressource
Liefert Ressource zurück
Grundlagen HTTPStruktur und Aufbau eines HTTP- Request/Response
Der prinzipielle Aufbau eines HTTP-Requestes oder Responses sieht wie folgt aus:
1) Startzeile mit Methode (CRLF)
2) 0-n Headerzeilen (CRLF)
3) Eine leere Zeile (CRLF)
4) 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: [email protected]
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
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:
Header
Größe in des folgenden Blocks in Hex.
Daten
Größe in des nächsten Blocks in Hex. DatenAbschlussmarkierung durch 0
Weiter Headerfelder
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
0
some-footer: some-value
another-footer: another-value
[Leerzeile]
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.
Erste Response mit „100 continue“
Eigentliche Response
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
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