Server

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.
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.
IP-Adresse
Port
Port
Port
Port
Name
Name
Name
Name
Adresse
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 HTTPServer, Mail-Server, FTP-Server usw.
Server
Client
Verbindung aufnehmen
Port
I/O Stream
Daten austauschen
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
I/O Stream
Daten austauschen
Port
I/O Stream
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)
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
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 mit Spaces Kodiert
Text%2emit%2ePunkt
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 Erzeugen
eines Clientsockets
Socket aSocket = new Socket(„host“, 8);
Beispiele für wichtige Methoden:
Name
Funktion
public void close()
InputStream getInputStream()
OutputStream getOutputStream()
void shutdownInput()
Void shutdownOutput()
Schließt den Socket
Liefert einen InputStream auf den Socket
Liefert einen OutputStream auf den Socket
Deaktiviert die Eingabe über den Socket
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 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:
Name
Funktion
Socket accept()
close()
int getLocalPort()
InetAddress getInetAddress()
Wartet auf eine Verbindung
Schliest den ServerSocket
Ermittelt die Portnummer des Sockets
Ermittelt das zugehörige InetAddress Objekt
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/userguide.html#AppendixUsingTheAxisTCPMonitorTcpmon
Installation: a) entpacken
b) CLASSPATH muss axis.jar beinhalten
c) Starten: java org.apache.axis.utils.tcpmon [listenPort targetHost targetPort]
Localhost
APP.
Server Socket auf
listenport
Tunnelhost
Tunnel
S
O
C
K
E
T
S
O
C
K
E
T
Ausgabe
S
O
C
K
E
T
Client Socket auf
tunnelport
APP.
Server 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 (HTMLFiles, 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:
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 CGISkript 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
Header
Transfer-Encoding: chunked
1a; [semikolon optional, wietere keys optional]
Größe in des folgenden Blocks in Hex.
abcdefghijklmnopqrstuvwxyz
Daten
10
1234567890abcdef
0
Größe in des nächsten Blocks in Hex.
Daten
Abschlussmarkierung durch 0
some-footer: some-value
another-footer: another-value
[Leerzeile]
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
Erste Response mit „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
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 IfUnodified-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