Theorie
 
 
 
 
 
Computertechnik
 
 
 
 
 
.. Stichwort: HTTP -Request/Response Message
 
 
 
 
 
 
 
 
 

 
Die Nachfrage eines Client-Computers nach Ressourcen von einem Server ist von einer, normalerweise nicht sichtbaren Kommunikation, zwischen den beiden Geräten begleitet. Beide Computer tauschen Daten untereinander aus.
Zunächst sendet der Client eine Request-Message (eine Nachfrage), dann reagiert der Server mit einer Response-Message (einer Antwort).

Beide Nachrichten lassen sich in einen Datenkopf (den Header) und einen Datenkörper (den Body) unterteilen. Dabei richtet sich der Datenkopf an den jeweiligen Computer gegenüber und enthält Eigenschaftsbeschreibungen zur Verbindung und zu den Nutzdaten, während der Datenkörper die eigentlichen Nutzdaten enthält.
Bei der Benutzung eines Browserprogramms, muss der Benutzer nur die Wichtigsten all dieser Daten an das Programm übergeben. Den Rest erledigt der Browser von sich aus. Soll der SC12 als Server fungieren, ist die Kenntnis der Daten, die zwischen beiden Geräten hin- und hergereicht werden, hilfreich. In der Folge werden die zwei Datensätze erläutert. Sendet / und versteht sie der SC12, so kann er Ressourcen von anderen Computern abrufen. Die Datensätze bestehen aus Strings (Zeichenketten), die mit den üblichen Mitteln der Programmierung erzeugt werden können.

 

 
 

 

 
1. Aufbau einer Request-Message
Die Kommunikation zwischen Client und Server beginnt mit einer Nachfrage des Client. Er sendet eine Request-Message in das Netz. Diese kann sich aus folgenden Elementen zusammensetzen. ..

 

 

 

 
Requestline *
                  (General Header | Request Header | Entity Header)
                                                                                      [Entity Body]

 

 

 

 

Es muss also eine Nachfragezeile (Requestline) existieren, der ein General Header oder ein Request-Header oder ein Entity-Header und wahlweise noch ein Entity-Body folgen können. Dabei werden der Entity Header und der Entity Body zunächst die Ausnahme sein. Entity Header und Body beschreiben Nutzdaten, die ein Client dem Server senden kann, was nicht so häufig auftritt. Häufiger ist wohl der Request Header, mit dem geschützte Daten vom Server angefordert werden können, doch zunächst zur Requestline ..

 

 

 

 

 

1.1. Requestline = METHOD   REQUEST-URL   HTTP-Version

 

 

Bsp:        GET   http://192.168.0.20:80/docs/seite.htm   HTTP/1.0\r\n

 

 

Die Nachfragezeile besteht aus der Angabe, welche Methode der Datenübertragung verwendet werden soll (beim SC12 gibt es GET, POST und HEAD), dann folgt der URL, dem wahlweise, durch einen ':' getrennt, das zu benutzende Tor (der Port 0-65535, HTTP Vorgabewert 80) beigefügt werden kann. Zuletzt wird die Version des HTTP-Protokolls angegeben, mit welcher der Client seine Nachfrage erstellt hat.

 

 

In dem Adressfenster eines Browsers wird vom Benutzer normalerweise nur die Request-URL eingetragen, und auch die wird weitgehend vom Browser vervollständigt, wenn z.B. die Protokollangabe http:// vergessen wurde. Das Tor setzt ein Browser bei http-Seiten auf den Vorgabewert 80. Will man diesen Wert überschreiben, so muss man wie oben angegeben, durch einen Doppelpunkt getrennt die gewünsche Tornummer mit eingeben.

 

 

 

 

 

 

1.1.1   Die Methode

 

 

 

1.1.2   Die Request-URL und ihre Kodierung

 

 

 

1.1.3   Die HTTP-Version

 

 

 

 

 

Üblicherweise ist mit der Requestline schon alles gesagt und eine normale Ressource kann vom Server gesendet werden. Manchmal sind aber weitere Angaben von Nöten, damit der Server etwas tut. Diese Angaben werden in einem der optionalen Header gemacht. Ein häufig anzutreffender Fall ist die Authentifizierung, .. der Nachweis, dass der Client ein zugelassener Nutzer der gewünschten Daten ist. Dies geschieht überwiegend durch einen Benutzernamen und ein Passwort. Dieser Fall soll folgend näher beleuchtet werden.

 

 

1.2. Request-Header= Authorization | from | if modified-since |                                                                        Referer | User-Agent

 

 

Bsp:           Authorization: Basic U2Nod2FyemVyOkdvQmxhY2s=\n

 

 
Durch ein Linefeed-Zeichen \n getrennt kann der Requestzeile eines der oben genannten weiteren Elemente folgen. Von denen wird hier die Benutzererkennung im Request-Header, die Authorization, weiter verfolgt.

Sie beginnt wie angegeben mit dem Schlüsselwort 'Authorization:', dann wird der Typ der nachfolgenden Verschlüsselung genannt. Im obigen Beispiel wurde der Typ Basic verwendet. Das bedeutet, dass der Benutzername und das Kennwort, in der Codierung 'Base64' verschlüsselt, folgen. Diese lauten im Beispiel ..
 
Benutzername:  Schwarzer
Kennwort:        GoBlack
 
Durch einen Doppelpunkt getrennt, und in ein Base64 Kodierungs-Dekodierungsprogramm eingegeben, ergibt sich daraus ..

Schwarzer:GoBlack --> U2Nod2FyemVyOkdvQmxhY2s=

Wird diese Zeile einem durch Benutzerkennung und Passwort geschützten Server übermittelt, dann sendet er die angeforderten Daten. Andernfalls verweigert er den Zugriff.

 

 

 

1.1.2.1   Der Request-Header

 

 

 

1.1.2.2   Die Benutzer Authentifikation

 

 

 

1.1.2.3   Die Base64 Kodierung

 

 

 

 

 
Die alternativen Möglichkeiten im Request Header bedeuten kurzgefasst ..

 

 

from

Hier kann die eigene eMail-Adresse genannt werden

 

 

if modified-since

Entity Body (Daten) nur dann senden, wenn das letzte Änderungsdatum nach dem angegebenen Datum liegt

 

 

 

 

 
2. Aufbau einer Response-Message
Auf die Nachfrage des Client reagiert der Server mit seiner Response-Message (Antwort). Diese besteht aus ..

 

 

 

 
Status-Line *
                  (General Header | Response Header | Entity Header)
                                                                                      [Entity Body]

 

 

 

 

In den meisten Fällen wird die Antwort des Servers aus der Statuszeile und dem Entity Body (den Nutzdaten) bestehen. Die Status Zeile enthält dabei folgende Angaben ..

 

 

2.1 Status-Line = HTTP-Version   Status Code   Reason-Phrase

 

 

Die Version des HTTP-Protokolls, den Statuscode und eine Erläuterung zum Statuscode, die Reason-Phrase

 

 

 

2.1.1   Die HTTP-Version

 

 

 

2.1.2   Der Status Code

 

 

 

 

 

2.2.1 General Header

 

 

2.2.2 Respose Header = Location | Server | www-Authenticate

 

 

Location

Den Standort des Servers

 

 

Server

Serverart und Version der Software

 

 

www-Authenticate

Bei Anfragen auf geschützte Ressourcen erscheinen Meldungen, dass sich der Client auszuweisen habe, und wie dies geschehen soll. Der Client ist nun aufgefordert, eine der Aufforderung entsprechende Antwort zu geben.

 

 
2.2.3 Entity Header = Allow | Content-Encoding |
                                  Content-Length | Content-Type |
                                  Expires | Last modified | Extension Header

 

 

Allow

Die Zugriffsmethode Get, Head, Post auf die Daten im Entity Body

 

 

Content-Encoding

Den Kompressionsalgorithmus der auf die Daten im Entity Body angewendet wurde, z.B. x-gzip

 

 

Content-Length

Die Länge der Daten in Bytes, im Entity Body

 

 

Content-Type

Den Mime-oder InhaltsTyp der Daten im Entity Body

 

 

Expires

Die Gültigkeitsdauer der Daten im Entity Body

 

 

Last modified

Das Datum der letzten Änderung der Daten im Entity Body

 

 

 

 

 

 

2.2.3   Die Mime-Typen

 

 

 

 

 
www..de