Hypertext Transfer Protocol

Größe: px
Ab Seite anzeigen:

Download "Hypertext Transfer Protocol"

Transkript

1 Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Hypertext Transfer Protocol Seminar: Internetprotokolle für die Multimediakommunikation Wintersemester 2002/2003 Markus Dobel Matrikelnummer: Betreuung: Carsten Pils Lehrstuhl für Informatik IV, RWTH Aachen

2 Inhaltsverzeichnis 1 Einleitung 2 2 Aufbau und Ablauf einer HTTP-Verbindung Anfrage (Request) GET/HEAD Conditional GET, Resume POST Sonstige Request-Methoden Antwort (Response) Response Header Status Codes und Statusmeldungen Content Negotiation Serverseitig Clientseitig Mechanismen zur Ressourcenoptimierung Virtuelle Server Persistente (dauerhafte) Verbindungen Proxy-Server, Caching HTTP und Sicherheit Zugriffsbeschränkung auf IP-Basis Authentication HTTPS Zusammenfassung und Ausblick 18 6 Abkürzungen 19 1

3 1 Einleitung Das Hypertext Transfer Protocol (HTTP) ist das Übertragungsprotokoll für Dokumente mit Querverweisen, sog. Links. Der erste Entwurfsvorschlag für ein solches Hypertext- System wurde laut [2] 1989 vom CERN- Mitarbeiter Tim Berners-Lee entwickelt. Die Idee dahinter war, einen einheitlichen Zugang zu Dokumentation aller Art zu schaffen, die dann mithilfe eines Browsers auf jedem beliebigen Rechner abrufbar war. Wichtig war dabei auch, bestehende Informationen ohne aufwendige Konvertierung in dieses System aufnehmen zu können wurde ein erstes solches System der High Energy Physics Community vorgestellt. Es bestand aus einem einfachen Browser, einem ersten Server sowie einer Funktionsbibliothek, auf deren Basis andere Entwickler eigene Applikationen bauen konnten. Etwas später wurde es dann über das Internet der breiten Öffentlichkeit (sofern man 1991 davon sprechen konnte) zur Verfügung gestellt. Anfang 1993 waren dann etwa 50 solcher Server bekannt. Zu diesem Zeitpunkt gab es im Wesentlichen zwei Browser. Zum einen die mittlerweile ziemlich fortgeschrittene Weiterentwicklung der oben angesprochenen Version, welche aber nur auf NeXT- Maschinen lief; zum anderen einen einfachen zeilenbasierten Browser, der auf allen Plattformen funktionierte, aber ziemlich eingeschränkt und wenig benutzerfreundlich war. Es wurde schnell klar, dass das CERN nicht allein für die Weiterentwicklung des Systems sorgen konnte, und so rief Berners-Lee übers Internet andere Entwickler dazu auf, daran mitzuwirken. Ebenfalls anfang 1993 veröffentlichte das National Center for Supercomputing Applications (NCSA) an der University of Illinois die erste Version ihres Browsers Mosaic für das schon derzeit in universitärem Umfeld weit verbreitete X Window System. Kurze Zeit später folgten ebenfalls Versionen für den PC und Macintosh. Dies war maßgeblich für den nun raschen Erfolg von HTTP verantwortlich. Bis Ende des Jahres hatte sich die Zahl der bekannten Webserver auf ca. 500 verzehnfacht, immerhin ein Prozent des damals erzeugten Traffics war mittlerweile dem WWW zuzuschreiben. Im Mai 1994 hielt das CERN die erste internationale WWW-Konferenz mit 400 Teilnehmern ab, die damals als Woodstock des Webs gefeiert wurde. Eine zweite Konferenz wurde im Oktober des Jahres vom NCSA und dem frisch gegründeten International WWW Conference Committee (IW3C2) einberufen, dieses Mal mit 1300 Teilnehmern. Ende 1994 gab es bereits Webserver (davon 2000 kommerziell) und 10 Millionen Nutzer. Man sprach vom Year of the Web. Es wurde stets darauf geachtet, alle weiteren das Web betreffenden Entwicklungen und die damit verbundenen Standards für alle offen zu halten. Dieser Aufgabe hat sich das ebenfalls 1994 gegründete Word Wide Web Consortium (W3C) verschrieben, ein Zusammenschluss von mittlerweile 500 Instituten und Firmen auf der ganzen Welt. Viele Sprachen und Protokolle sind dem W3C zu verdanken, angefangen bei Hypertext Markup Language (HTML) und Cascading Style Sheets (CSS), Extensible Markup Language (XML) und seinen Anwendungen wie beispielsweise das Simple Object Access Protocol (SOAP) oder dem Ressource Description Framework (RDF), aber auch z.b. das Bildformat Portable Network Graphics (PNG) und natürlich auch der aktuellen Version des Hypertext Transfer Protocol, HTTP 1.1. Diese Arbeit soll einen Überblick über die Funktionsweise und Möglichkeiten von HTTP geben, aber auch Grenzen des Protokolls aufzeigen. Zunächst wird der Aufbau und der Ablauf des Protokolls erklärt. In Abschnitt 3 werden Aspekte der Ressourcenersparnis betrachtet und Abschnitt 4 geht auf das Thema Sicherheit im Bezug auf HTTP ein. 2

4 2 Aufbau und Ablauf einer HTTP-Verbindung Eine HTTP-Verbindung besteht grundsätzlich aus dem Austausch zweier Nachrichten, den sogenannten HTTP-Messages. Das Format dieser Nachrichten entspricht dem allgemeinen Format für Internet Messages (siehe [3]), welches auch bei und Usenet News Anwendung findet. Eine Message besteht aus zwei Teilen. Der erste Teil ist der Header bestehend aus einer Startzeile (Request-Zeile beim Request und Statuszeile beim Response) und in der Regel mehreren weiteren Headerzeilen, die die Message weiter beschreiben. Eine Headerzeile hat die Form Feldname: Feldwert, wie in Abbildung 1 zu sehen ist. Host: Abbildung 1: Beispiel eines Headers Der zweite Teil der Nachricht ist der sogenannte Body, der Inhalt der Nachricht. Bei einem Response befindet sich darin beispielsweise der Inhalt der angeforderten Datei. Dieser Teil kann auch leer sein. Die beiden Teile einer Nachricht werden durch eine Leerzeile voneinander getrennt. Abbildung 2 zeigt eine solche Nachricht am Beispiel eines GET- Requests. GET /index.html HTTP/1.1 Host: Accept-Language: de User-Agent: Mozilla/4.0 } } } Request-Line / Status-Line Header-Zeilen Body Abbildung 2: Eine HTTP-Message Grundsätzlich gibt es zwei Typen von Nachrichten, die vom Browser (im folgenden Client genannt) geschickte Anfrage (Request) und die vom Server daraufhin generierte Antwort (Response). In Abbildung 3 wird ein einfacher Nachrichtenaustausch dargestellt. Im Allgemeinen ist die HTTP-Verbindung nach dem Austausch dieser beiden Nachrichten beendet, folgende Anfragen haben protokolltechnisch keinen Bezug zu vorhergehenden. HTTP ist im Unterschied zu anderen Protokollen zustandslos. Die Übertragung einer Webseite mit all ihren Bildern stellt auf Protokollebene viele einzelne HTTP-Verbindungen dar, für jede Datei eine. Es gibt prinzipiell keine Sessions wie bspw. Telnet, FTP o.ä., bei dem der Benutzer sich anmeldet und nach Beendigung der Arbeit wieder abmeldet. 3

5 Request Response Client Server Abbildung 3: Einfacher Nachrichtenaustausch 2.1 Anfrage (Request) Ein Request ist eine Nachricht vom Client zum Server. Die erste Zeile eines Requests, die sogenannte Request Line, beinhaltet die Art der Anfrage, die sogenannte Request Method sowie die URL der angeforderten Ressource und die benutzte HTTP-Version. Die folgenden Headerzeilen geben weitere Informationen über die Anfrage oder den Client. Die meisten Browser schreiben ihren Produktnamen und -Version in eine Headerzeile, oder geben an, welche Landessprache der Benutzer bevorzugt. Ebenfalls ist es mittlerweile üblich, dass sich mehrere Webangebote einen physikalischen Server teilen (virtual hosting). Damit der Server nun weiß, von welchem der virtuellen Server nun ein Dokument gewünscht wird, fügt der Client einen Host-Header wie in Abbildung 1 seinen Request ein. Dieser Header ist bei HTTP 1.1 sogar zwingend vorgeschrieben. Abbildung 4 zeigt einen üblichen Request. GET /~mdobel/index.php HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows~2000) Host: balu.kawo2.rwth-aachen.de Accept: text/html, image/png, image/jpeg, image/gif, */* Accept-Language: de,en Accept-Charset: utf-8;q=1.0, iso ;q=0.6, *;q=0.1 Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 Abbildung 4: Ein typischer HTTP-Request Bei der ersten Zeile handelt es sich um die besagte Request Line. Als nächstes folgt der User-Agent. Hier gibt der Browser Informationen über seinen Namen, Version und das Betriebssystem aus, er identifiziert sich als MSIE 5.0. Diese Information muss nicht immer stimmen, es gibt mittlerweile Browser, bei denen man genau diesen Header frei wählen kann. Als nächstes sagt er dem Server, dass er die Ressource von dem Host balu.kawo2.rwth-aachen.de haben möchte. Der Rest der Header dient der sogenannten Content Negotiation, auf die in Abschnitt näher eingegangen wird. Es gibt noch weitere Header, die im Laufe dieses Textes näher beschrieben werden. Dieser Request wird mit einer Leerzeile beendet, ein Body folgt nicht. 4

6 2.1.1 GET/HEAD Bei GET handelt es sich um die wohl am häufigsten verwendete Request-Methode, es wird einfach die in der URI angegebene Ressource (Eine HTML-Seite, ein Bild) angefordert. Wie schon gesagt, besitzt ein GET keinen Body. Sehr wohl können in einem GET-Request jedoch weitere Parameter übergeben werden, beispielsweise bei der Formularverarbeitung. Dies findet unter anderem Anwendung bei Suchmaschinen, denen man den Suchbegriff in der URL mitgibt. Die weiteren Parameter müssen dabei URL-encoded (siehe [4]) angehangen werden. Wenn man z.b. in die Suchmaske von die Wörter informatik 4 rwth aachen eingibt, erstellt der Browser beim Absenden des Formulars einen Request wie diesen (vereinfacht): GET /search?q=informatik+4+rwth+aachen Host: Die hier angeforderte Ressource ist ein Beispiel dafür, dass nicht nur statische Daten ausgeliefert werden können, sondern ein Server auf Anforderung einer Ressource hin diese erst generiert. Bei einer Suchmaschine sucht der Server alle zu den Suchbegriffen passenden URLs aus seiner Datenbank und liefert diese in HTML aufbereitet an den Client aus. Der HEAD-Request ähnelt dem GET-Request sehr, auf Client-Seite ist er bis auf den Request-Namen identisch. Der Server wird damit angewiesen, in seiner Antwort nur die Header auszufüllen, den Body jedoch leerzulassen. Damit erhält der Client alle Metainformationen über die Ressource (Größe der Datei, Datum der letzten Änderung), ohne sie herunterladen zu müssen. Dies kann z.b. dazu verwendet werden, herauszufinden, ob eine Datei sich seit einem vorhergegangenen GET-Request verändert hat Conditional GET, Resume Außer dem HEAD-Request gibt es weitere Möglichkeiten des bedingten GET-Requests. Beispielsweise kann ein Browser dem Server mitteilen, dass er die Ressource nur dann haben will, wenn die auf dem Server liegende Version neuer ist als die im Cache des Browsers befindliche. Dazu können die in Abbildung 5 aufgezählten Header verwendet werden. If-Modified-Since: <Datum> If-Unmodified-Since: <Datum> If-Match: <ETag> If-None-Match: <ETag> Abbildung 5: Header für bedingte Requests ETag ist hierbei ein Entity-Tag. Entity-Tags sind eindeutige Strings, die verschiedene Entitäten einer Ressource bezeichnen. Beispielsweise ist die Webseite einer Tageszeitung an unterschiedlichen Tagen auch mit unterschiedlichen Daten gefüllt. Entsprechend hätte die Homepage auch an beiden Tagen unterschiedliche Entity-Tags. Ein Server kann einer Ressource einen solchen eindeutigen Tag (in einfachsten Fall eine laufende Nummer) in einem Response-Header mitgeben, damit ein Client später diesen Tag als Vergleichsmittel für einen bedingten wiederholten GET der selben Ressource verwenden kann. 5

7 Es kann auch vorkommen, dass der Download einer großen Datei auf Grund von Netzwerkproblemen abbricht. Damit der Client nun nicht noch einmal die ganze Datei herunterladen muss, kann er dem Server mitteilen, dass er nur einen bestimmten Abschnitt einer Datei haben möchte. Dies geschieht mit dem folgenden Header: Range: <Range-Specifier> Zuletzt kann man auch beides kombinieren. Der Client kann somit sagen, dass er den im Range-Header angegebenen Abschnitt nur dann haben möchte, wenn er zu dem schon vorhandenen Teil passt, denn zwischen den beiden Download-Versuchen kann sich die Ressource ja auch verändert haben. Dazu kann der folgende Header benutzt werden: If-Range: <ETag> oder <Datum> Passt das angegebene Kriterium zur aktuellen Entität der Ressource, wird der Server nur den angeforderten Abschnitt ausliefern, ansonsten wird noch einmal die gesamte Entität gesendet POST Abbildung 6: Ein Webformular POST-Requests werden vor allem bei der Auswertung von Webformularen (siehe Abbildung 6) verwendet. Die Eingaben des Formulars werden hierbei im Body übermittelt. Dies stellt auch einen großen Unterschied zu GET dar, mit dem ebenfalls Formulardaten übermittelt werden können. Bei GET werden diese jedoch mit in der URL encoded. Dieser technisch kleine Unterschied wirkt sich in der Praxis wie folgt aus: Das Ergebnis eines mit GET ausgefüllten Formulars lässt sich als Bookmark ablegen, da es sich nur um eine (evtl. lange und kryptische) URL handelt. Das ist mit POST zumindest mit aktuellen Browsern nicht möglich. Dafür tauchen ggf. aber auch alle Formularwerte in den Logfiles etwaiger Proxyserver (siehe Abschnitt 3.3) auf, die jede angeforderte URL protokollieren. Damit verbietet sich der Gebrauch von GET bei der Übermittlung von Passwörtern nahezu (sofern man dort nicht sowieso das in Abschnitt 4.3 angesprochene HTTP Secure sockets (HTTPS) verwenden sollte). 6

8 Die Länge der gesamten Formulardaten ist bei GET durch die maximale URL- Länge nach oben begrenzt, somit lassen sich große Formulare nur mit POST realisieren. Dateiuploads in Formularen sind generell nur mit POST möglich. (Quelle: [6]) Sonstige Request-Methoden Es gibt noch weitere, seltener verwendete Request-Methoden. Dies sind PUT und DE- LETE, CONNECT, OPTIONS sowie TRACE, welche im folgenden beschrieben werden. Zuletzt ist es natürlich auch möglich, HTTP um eigene Requestmethoden zu erweitern. PUT und DELETE dienen der direkten Manipulation von Dateien auf einem Web-Server. Mit PUT kann ein Client eine Datei auf einen Server hochladen, mit DE- LETE eine vorhandene Datei löschen. Im Unterschied zu POST, mit dem auch Dateiuploads möglich sind, beschreibt die bei PUT mitgeschickte URL nicht den Ort eines Prozessors (Script) zur Verarbeitung der mitgeschickten Daten, sondern es handelt sich bei der URL um den gewünschten Ablageort der Datei. PUT kann auch nicht für Webformulare verwendet werden. Dennoch ist ähnlich wie bei POST die Datei im Body des Requests enthalten. Diese beiden Request-Methoden finden beispielsweise Anwendung bei den sogenannten Web-Folders (siehe [7]) von Microsoft Windows, mit denen sich ein Verzeichnis auf einem HTTP-Server ähnlich einer Windows-Netzwerkfreigabe verwenden lässt. Es sei noch angemerkt, dass wohl jeder ordentlich konfigurierte HTTP-Server diese beiden Methoden natürlich nicht für jedermann zulässt, sondern allenfalls einem eingeschränkten Benutzerkreis zur Verfügung stellt. Möglichkeiten zur Einschränkung werden in Abschnitt 4 vorgestellt. CONNECT weist einen Proxyserver an, eine Verbindung zu einem weiteren Server herzustellen und den Datenstrom unverändert zwischen den beiden beteiligten Hosts durchzureichen. OPTIONS kann ein Client dazu benutzen, um feststellen, was für Optionen der Server bezüglich der angegebenen URL bietet. Der Server kann hier auch angeben, welche optionalen Features und Erweiterungen des HTTP- Standards er unterstützt. TRACE dient Diagnosezwecken (ähnlich traceroute auf IP- Ebene). Man kann damit herausfinden, wie viele Proxyserver sich zwischen Client und Server befinden. 2.2 Antwort (Response) Die Response ist die zweite Hälfte eines HTTP-Dialogs, es handelt sich dabei um die Antwort des Servers auf den vom Client gestellten Request. Auch hier nimmt die erste Zeile, die sogenannte Status-Line eine besondere Rolle ein. Sie besteht aus der vom Server verwendeten HTTP-Version, einem numerischen Status-Code sowie einer textuellen Statusmeldung, jeweils getrennt durch ein Leerzeichen und gefolgt von einem 7

9 Zeilenumbruch. Danach folgen (wie schon aus Abbildung 2 bekannt) weitere Header sowie der Body. Abbildung 7 zeigt eine typische Antwort. HTTP/ OK Date: Sat, 15 Oct :02:38 GMT Server: Apache/ (Unix) (Red-Hat/Linux) Connection: close Content-Type: text/html; charset=iso <HTML> <HEAD>... (Inhalt der HTML-Datei) Abbildung 7: Eine typische HTTP-Response Response Header Response Header haben die gleiche Form wie in Abbildung 1 und ermöglichen es, weitere Informationen über die Antwort zu erteilen, die nicht in der Status-Line wiedergegeben werden können. Beispielsweise können hier Aussagen über die Größe oder das Alter eines Dokumentes getroffen werden. Häufig werden Response Header auch dazu genutzt, Informationen über den Server (eingesetzte Software, Version, Erweiterungen) zu liefern Status Codes und Statusmeldungen Der Status-Code ist eine aus drei Ziffern bestehende Zahl, die den Erfolg/Misserfolg der Bearbeitung eines Requests darstellt. Einem numerischen Code ist eine textuelle Repräsentation zugeordnet, eine menschenlesbare Version des numerischen Codes. Diese Status-Codes sind in fünf Klassen unterteilt. Die Klasse der 1xx Sta- 1xx : Informational - Response ist informeller Natur tus Codes beinhaltet in HTTP/1.1 nur zwei Codes. Mit 100 (Continue) weist der Server den Client an, seinen Request fortzusetzen. Dies kann z.b. bei einem großen Formular genutzt werden. Der Client sendet dabei zunächst nur den Head seines Requests und sendet dabei diesen Header mit: Expect: 100-continue Dieser Header besagt, dass der Client einen 100 (Continue) Response erwartet, bevor er den Body sendet. Ist der Server unter der angeforderten URL nicht gewillt, POST-Requests zu bearbeiten, kann er mit einem 4xx- Request antworten und der Client muß den unter Umständen großen Body nicht senden. Mit 101 (Switching Protocols) kündigt der Server an, dass er vom aktuellen Protokoll auf ein anderes wechselt. Dies kann in der Zukunft von Interesse sein, wenn Client und Server eine neuere Version von HTTP unterstützen. Mit folgendem Header kann ein Client ankündigen, welche Protokolle er unterstützt: 8

10 Upgrade: <Protokoll>[, <Protokoll>...] Ein Server würde in seinem Response dann einen ähnlichen Header mitsenden, der nur das gewählte Protokoll beinhaltet. 2xx: Success - der Request wurde vollständig empfangen, verstanden und akzeptiert. Mit einem 2xx-Statuscode signalisiert der Server, dass die Anfrage erfolgreich war. Im Body der Nachricht befindet sich üblicherweise die angeforderte Ressource. 200 (OK) ist der häufigste Statuscode. Er beschreibt lediglich, dass der gewünschte Request wie erwartet bearbeitet wurde und liefert im Body das Ergebnis zurück. Mit 201 (Created) antwortet der Server üblicherweise auf erfolgreiche PUT-Requests. Dieser Statuscode besagt, dass eine neue Ressource angelegt wurde. 204 (No Content) wird dann zuruückgegeben, wenn der Server den Request ausgeführt hat, jedoch für die Antwort kein Body notwendig ist. Dies kann bei Formularen verwendet werden, mit denen ein Benutzer eingaben tätigen kann. 205 (Reset Content) ähnelt dem Statuscode 204, jedoch wird der Client angewiesen, die aktuelle Dokumentenansicht (bspw. das Formular, das den Request bedingt hat) zurückgesetzt werden soll. Auf die Art und Weise kann ein Benutzer auf einfache Weise weitere Eingaben tätigen und absenden. 206 (Partial Content) ist die Antwort auf einen partiellen GET- Request, wie er in Abschnitt beschrieben wird. 3xx: Redirection Ein 3xx-Statuscode besagt, dass die gewünschte Ressource nicht direkt unter der angeforderten URL verfügbar ist, gibt dem Client aber Informationen darüber, was zu tun ist, um die angeforderte Ressource zu bekommen. Im Allgemeinen handelt es sich hierbei um Umleitungen temporärer oder dauerhafter Art, weil das Dokument auf dem Server verschoben wurde. Die URL, unter der die gewünschte Ressource zu finden ist, schickt ein Server dabei in einem Header mit, der die folgende Form hat: Location: <URL> Die angegebene URL muss dabei absolut sein. Zusätzlich dazu gibt es noch zwei weitere Header: 300 (Multiple Choices) besagt, dass der Server mehrere alternative Repräsentationen eines Dokuments zur Verfügung hat. Im Body der Antwort werden dem Client die URLs der verschiedenen Repräsentationen mitgeteilt, dieser kann diese dann zur clientseitigen Content Negotiation verwenden (siehe 2.3.2). Mit 304 (Not Modified) antwortet der Server auf einen bedingten GET-Request (siehe 2.1.2), wenn die angeforderte Ressource verfügbar ist, sich aber entsprechend der im Request mitgelieferten Header nicht verändert hat. Eine solche Antwort enthält keinen Message-Body. 9

11 4xx: Client Error Die Klasse der 4xx-Statuscodes weist den Client darauf hin, dass entweder sein Request fehlerhaft war oder aber möglicherweise unvollständig und daher nicht beantwortet werden kann bzw. darf. Im Body einer solchen Fehlermeldung sollte ein Server eine genauere Erklärung des Fehlers mitliefern und eine Aussage darüber, ob dieser Fehler temporärer oder dauerhafter Natur ist. Im Folgenden sind einige gebräuchliche 4xx-Statuscodes aufgelistet. 400 (Bad Request) beschreibt einen Syntaxfehler des Clients. Mit 401 (Unauthorized) beantwortet ein Server einen Request, für deren Beantwortung sich der Benutzer authentifizieren muss (siehe 4.2). Sollte ein Client in diesem Request schon Authentifizierungsinformationen mitgeliefert haben, besagt eine solche Antwort, dass diese Informationen nicht (mehr) gültig sind und sich der Benutzer erneut anmelden muss. 403 (Forbidden) heißt, dass es dem Client nicht erlaubt ist, die angeforderte URL zu erhalten; im Gegensatz zum 401 auch nicht nach einer Authentifizierung. Im Body einer solchen Nachricht sollte der Server einen Grund mitliefern, der genauer beschreibt, wieso der Client die gewünschte Information nicht erhalten darf. Wenn ein Server kein zur URL passendes Dokument findet, sendet er ein 404 (Not Found). Es wird jedoch keine Aussage darüber getroffen, ob diese URL absichtlich oder versehentlich fehlt, oder ob dies temporärer oder dauerhafter Natur ist. Wenn eine Ressource absichtlich, dauerhauft und ersatzlos gelöscht wurde, sollte ein Server besser ein 410 (Gone) senden. 404 (Not Found) kann auch verwendet werden, wenn der Client die Ressource nicht erhalten darf, der Server jedoch keine Aussage darüber treffen kann oder will, warum er die angeforderte Ressource nicht ausliefert. 406 (Not Acceptable) ist Teil der serverbasierten Content Negotiation (siehe 2.3.1). Der Server konnte keine Repräsentation der angeforderten Ressource finden, die zu den Accept-*-Headern passt, die im Request mitgesendet wurden. Wenn z.b. ein Client ausdrücklich keine englische Seite wünscht, der Server aber das Dokument nur in englisch vorhält, muß der Server mit dem Status Code 406 antworten. 5xx: Server Error Mit der Klasse der 5xx-Statuscodes weist der Server darauf hin, dass der Request zwar fehlerfrei war, der Server ihn jedoch aufgrund eines Fehlers auf seiner Seite nicht beantworten kann. 500 (Internal Server Error) weist meistens auf einen Konfigurations- oder Programmierfehler im Server hin. Der Server befindet sich in einem unerwarteten Zustand und kann den Request nicht bearbeiten. 501 (Not Implemented) besagt, dass der Server die angeforterte Request-Methode nicht kennt und daher den Request nicht bearbeiten kann. mit 503 (Service Unavailable) kann ein Server daraufhindeuten, dass er den Request zur Zeit (bswp. wegen Überlast oder Wartungsarbeiten) nicht bearbeiten kann. Dies heisst jedoch nicht, dass ein Server dazu verpflichtet ist, bei Überlast einen 503 Response zu senden. 10

12 504 (Gateway Timeout) wird vorrangig von Proxyservern verwendet. Dieser Statuscode deutet darauf hin, dass der Proxy keine Antwort vom Server erhalten hat oder aber der für den Request benötigte DNS-Lookup nicht in angemessener Zeit beantwortet wurde. Mit 505 (HTTP Version Not Supported) antwortet ein Server, der die im Request angezeigte HTTP-Version nicht beherrscht und daher den Request nicht bearbeiten kann. 2.3 Content Negotiation Es ist für einen Server möglich, mehrere Repräsentationen einer Ressource unter der selben URL vorzuhalten. Denkbar sind beispielsweise Seiten in verschiedenen Sprachen oder verschiedene Bildformate des selben Motivs. Genauso könnte ein Server ein Dokument komprimiert an einen Client ausliefern, um Bandbreite zu sparen; vorrausgesetzt, der Client unterstützt dies. Unter Content Negotiation versteht man Mechanismen, um festzustellen, welche Repräsentation eines Dokuments nun ausgeliefert bzw. heruntergeladen werden soll. Solche Mechanismen sind sowohl auf Server- als auch auf Clientseite möglich, man kann auch beides kombinieren Serverseitig Bei der serverseitigen (server-driven) Content Negotiation entscheidet der Server anhand verschiedener Parameter, welche Repräsentation einer Ressource für den Client am besten ist. Als Anhaltspunkte für diese Entscheidung kann der Server vom Client mitgeschickte Header oder aber auch beispielsweise die IP-Adresse des Clients nehmen. Für diesen Mechanismus stellt HTTP verschiedene Request-Header zur Verfügung, von denen einige bereits in Abbildung 4 vorgestellt worden sind. GET /~mdobel/index.php HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows~2000) Host: balu.kawo2.rwth-aachen.de Accept: text/html, image/png, image/jpeg, image/gif, */* Accept-Language: de,en Accept-Charset: utf-8;q=1.0, iso ;q=0.6, *;q=0.1 Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 Abbildung 8: Ein typischer HTTP-Request Der Server hat hier nun verschiedene Anhaltspunkte, anhand derer er entscheiden kann, was er dem Browser ausliefert. User-Agent: Jeder Browser hat leicht unterschiedliche Ansichten darüber, wie HTML- Code dargestellt werden soll. Der Server könnte dieses Feld auswerten um eine speziell für den Browser angefertigte Seite auszuliefern. Accept: Hiermit gibt ein Client an, welche Dateitypen er verarbeiten kann. Ein Dateityp wird in der folgenden Form angegeben: <type>/<subtype> 11

13 Dabei steht ein Stern (*) für alle Typen bzw. Subtypen. Beispielsweise hat der Typ image u.a. die Untertypen gif, jpeg, bmp oder png. Das oben gezeigte Beispiel ist aus einem reellen Request und zeigt, wie wenig sinnvoll dieser Header in aktuellen Browserimplementationen verwendet wird. Der dort benutzte Browser zeigt an, dass er neben verschiedenen Dateitypen auch alle nicht genannten Dateitypen gleich gut verarbeiten kann. Die Angabe von vier bestimmten Typen wäre also unnötig gewesen. Ausserdem kann dieser Header nicht sinnvoll von einem Server zur Entscheidungsfindung verwendet werden. Accept-Language: Mit diesem Header sagt ein Client aus, welche Sprachen sein Nutzer spricht und welche er priorisiert. Ein Server, der den gleichen Text in verschiedenen Sprachen vorhält, kann anhand dieses Headers die für den Anwender beste Übersetzung auswählen und zurücksenden. Accept-Charset: Mit diesem Header zeigt der Client an, welche Zeichensätze er versteht und anzeigen kann. Wie schon beim Accept-Header bedeutet ein * anstatt eines Zeichensatznamens alle Zeichensätze. Accept-Encoding: Dieser Header ist ähnlich dem Accept-Header zu verstehen, er bezeichnet allerdings nicht die vom Client verstandenen Medientypen, sondern die Kodierungen, in denen er den Request-Body erwartet. In diesem Fall handelt es sich um verschiedene Kompressionsalgorithmen, mit denen der Server den Inhalt des Dokumentes vor Versand komprimieren kann, um Bandbreite zu sparen. Sämtlichen beschriebenen Attributen in Accept-Headern kann ein Client die im Beispiel beim Accept-Charset-Header verwendeten sogenannten Quality-Faktoren hinzufügen. Ein solcher Faktor hat die Form q=x und wird dem Attribut mit einem Semikolon angehängt. x kann dabei einen beliebigen Fliesskommawert zwischen 0 und 1 annehmen und beschreibt die Priorität der verschiedenen Alternativen. Ein Quality-Faktor von 0 bedeutet dabei, dass der Client mit der entsprechenden Eigenschaft (Sprache, Encoding) nichts anfangen kann. Sollte ein Server eine Ressource nur in einer Form vorhalten, die der Client mit einem Faktor von 0 versehen hat, sollte in einem solchen Fall mit der Fehlermeldung 406 (Not acceptable) antworten. Im Accept-Language-Header kann man eine Abweichung gängiger Praxis von der Standardbeschreibung sehen. Dort wird gesagt, dass die Priorität der Sprachen ebenfalls über Quality-Faktoren zu setzen ist, viele Browser definieren die Priorität jedoch einfach über die Reihenfolge der Sprachkürzel. Serverseitige Content Negotiation ist ein zweischneidiges Schwert. Ein Vorteil ist, dass anhand eines einzigen Requests entschieden wird, welche Repräsentation die beste für den Client und Benutzer ist. Dem gegenüber stehen jedoch eine Reihe Nachteile bzw. zu beachtender Vorsichtsmaßnahmen. Zum Beispiel kann ein Server anhand der gegebenen Möglichkeiten nicht wissen, ob ein User ein Dokument auf dem Bildschirm betrachten will oder vielleicht ausdrucken möchte, falls er für diese Zwecke verschiedene Repräsentationen hat. Ebenfalls könnte es sein, dass ein Benutzer ein bestimmtes Dokument unbedingt in der Originalsprache haben möchte, unabhängig seiner sonstigen sprachlichen Präferenzen. Ein Serverbetreiber sollte hier darauf achten, dass trotz automatischer Negotiation auch die anderen Versionen eines Dokuments erreichbar und für Benutzer auffindbar sind. Auch lässt die Implementierung in aktuellen Clients oftmals zu wünschen übrig, sodass die praktische Anwendbarkeit zumindest fraglich 12

14 ist. Zuletzt sind solche Responses nicht sinnvoll durch Proxies cachebar, da ein zwischengeschalteter Proxyserver nicht weiss, anhand welcher Parameter ein Server nun welche Repräsentation ausliefert Clientseitig Bei der clientseitigen Content Negotiation liefert ein Server auf einen Request zuerst eine Liste von alternativen, unter verschiedenen URLs erreichbaren Repräsentationen, aus denen sich der Client die für ihn beste aussuchen und in einem weiteren Request herunterladen kann. Dies kann - sofern der Client dazu in der Lage ist - automatisch oder aber manuell durch den Anwender geschehen, indem dieser die ihm liebste Repräsentation auswählt. Diese Methode hat den Vorteil, dass sie dem Benutzer eine größere Gewalt darüber gibt, das beste aus der Reihe der Alternativen auszuwählen. Abgesehen davon lassen sich diese Antworten leicht von Proxies cachen, da jede Repräsentation über eine eigene URL verfügt. Ein Nachteil der clientseitigen Content Negotiation liegt darin, dass zwei Requests nötig sind, um die geeigneteste Alternative zu erhalten. Es gibt auch keine Spezifikationen darüber, wie ein Client eine automatische Auswahl tätigen könnte, sodass letzten Endes jedes Mal der Anwender in Form von zwei Aktionen darüber entscheiden müsste, welche Repräsentation er haben möchte. 3 Mechanismen zur Ressourcenoptimierung 3.1 Virtuelle Server Im Laufe der Jahre sind IPv4-Adressen zu einem knappen Gut geworden, gleichzeitig ist, auch im Zuge der Kommerzialisierung des Web, die Zahl der Webseiten stark gestiegen. In HTTP/1.1 wurde dieser Tatsache Rechnung getragen, indem sogenannte Name Based Virtual Hosts eingeführt wurden. Dieses Feature ermöglicht es, auf einem Server mit nur einer IP-Adresse beliebig viele Webseiten mit verschiedenen Hostnamen zu betreiben. Erforderlich hierfür ist, dass ein Client bei jedem Request angibt, von welchem Hostnamen er die genannte Webseite haben möchte, also einen sogenannten Host- Header mitsendet, welche diese Form haben: Host: Große Webspace-Provider wie Strato oder 1&1 machen von diesem Feature regen gebrauch. 3.2 Persistente (dauerhafte) Verbindungen Grundsätzlich überdauert eine HTTP-Verbindung nur den Austausch zweier Nachrichten, i.d.r. also nur die Übertragung einer Datei. Für die Übertragung einer Webseite mit allen eingebetteten Objekten (Bilder etc.) muß also pro Datei eine Verbindung zum Server aufgebaut und nach der Übertragung der aktuellen Datei geschlossen werden, um sofort wieder eine neue Verbindung aufzubauen. 13

15 Vor HTTP/1.1 war dem ausnahmslos so und man stellte fest, dass dies verhältnismäßig viele Ressourcen und Zeit verbraucht, denn für jeden Verbindungsaufbau werden insgesamt 3 leere TCP-Pakete zwischen den beiden beteiligten Rechnern verschickt, bevor das erste Byte des Requests versendet wird. Für einen Verbindungsabbau sind noch einmal 2 Pakete ohne Nutzdaten fällig. Daher wurde HTTP mit dem Feature sogenannter Persistent Connections versehen, mit denen mehrere Request/Response- Paare über eine TCP-Verbindung ausgetauscht werden können, seit HTTP/1.1 ist die Implementierung dieses Features in Clients und Servern auch Pflicht. Dies ändert jedoch an der Zustandslosigkeit von HTTP nichts, auch stehen die verschiedenen Requests, die über einen solchen persistenten Kanal geschickt werden, nicht notwendigerweise in direktem Zusammenhang zueinander (man bedenke bspw. dass ein Proxy zwei gleichzeitig auf den selben Webserver zugreifende Clients bedienen könnte). Gesteuert werden diese dauerhaften Verbindungen über die Header Connection sowie Keep-Alive. Wünscht ein Client, dass die Verbindung geöffnet bleibt, kann er seinem Request folgenden Header hinzufügen: Connection: Keep-Alive Da dieses Verhalten seit HTTP/1.1 jedoch standard ist, kann der Header in diesem Fall auch weggelassen werden. Wünscht der Client, dass die Verbindung nach dem aktuellen Request geschlossen wird (weil er gerade die letzte Datei einer Webseite lädt), so sollte er dies mit dem folgendem Header anzeigen: Connection: close Das gleiche gilt auch für den Server, welcher optional noch mit jeder Antwort einen weiteren Header mitsenden kann: Keep-Alive: timeout=x, max=y Hierbei steht timeout=x für die Anzahl Sekunden, nach denen der Server die Verbindung schließt, falls kein Request mehr ankommt und max=y besagt, wieviele Requests der Server maximal über eine Verbindung verarbeitet. Senden Server oder Client innerhalb eines Request/Response-Paares ein Connection: close, muss die Verbindung nach Verarbeitung des aktuellen Requests geschlossen werden. 3.3 Proxy-Server, Caching Proxy-Server sind Mittelsmänner, die Requests von Clients annehmen und an Server weiterleiten und die Antworten vom Server wiederum an die Clients weiterleiten. Der Einsatz eines Proxy-Servers für HTTP kann vielerlei Gründe haben. Zum einen kann es sein, dass eine Gruppe von Clients keine direkte Verbindung zum Internet, wohl aber zum eigenen Proxy aufbauen kann (bspw. Firmen-Netzwerk mit restriktiver Firewall), zum anderen können Proxies auch Server-Antworten zwischenspeichern (cachen). Somit muss der Proxy bei wiederholten Requests auf die selbe URL nur noch die gespeicherte Kopie ausliefern. Damit sparen sowohl der Serverbetreiber als auch der Betreiber des Netzes hinter dem Proxy Netzlast und auch Übertragungszeit. Man denke beispielsweise an Softwarepakete, die direkt nach ihrer Veröffentlichung von tausenden Clients heruntergeladen werden. Der zweite und alle folgenden Clients bekommen die zwischengespeicherte Kopie direkt und schnell von der Festplatte des Proxies über das 14

16 schnelle LAN, anstatt möglicherweise auf eine langsame Überseeverbindung warten zu müssen. Genau der gleiche Ansatz kann und sollte auch im kleineren Maßstab direkt in Clients verfolgt werden, in Form von lokalen Browser-Caches. Beispielsweise befinden sich auf vielen Webseiten Grafiken wie ein Firmenlogo oder grafikbasierte Navigation, die sich auf jeder Seite wiederholen. Damit diese Grafiken nicht für jede neue Seite erneut geladen werden müssen, empfiehlt es sich, diese lokal zu cachen. Selbiges gilt für die zuletzt besuchten Webseiten, so dass beim Drücken des Zurück -Knopfes im Browser die vor wenigen Momenten geladenen Seiten nicht noch einmal übertragen werden müssen. Jedoch sind nicht alle Objekte ewig zwischenspeicherbar. Beispielsweise ist eine Wettervorhersage von vorgestern ähnlich uninteressant wie ein Webcam-Bild der vergangenen Nacht. Somit ist es notwendig, sowohl Server als auch Client mit Mechanismen zur Steuerung der maximalen Cache-Dauer auszurüsten. In HTTP/1.0 gab es nur zwei Header, um Caches zu steuern. Ein Server konnte einem Dokument einen Expires-Header auf den Weg geben: Expires: Sat, 19 Oct :00:00 GMT Dieser Header besagt, dass eine Ressource ab dem angegebenen Datum als abgelaufen gilt und ein Cache oder Client eine zwischengespeicherte Version dieses Dokuments nach diesem Zeitpunkt nicht nochmals ausgeliefert/angezeigt werden sollte, ohne zuerst überprüft zu haben, ob mittlerweile eine neuere Version auf dem Server vorhanden ist. Dies ist beispielsweise mit einem aus Abschnitt bekannten bedingten Request möglich. Ein Client konnte in HTTP/1.0 mit folgendem Header anzeigen, dass er auf jeden Fall eine neue Version einer URL haben wollte, auch wenn ein auf dem Weg liegender Cache eine noch gültige Version zwischengespeichert hat: Pragma: no-cache Mit HTTP/1.1 ist ein weiterer Header eingeführt worden, der Cache-Control- Header, mit denen sowohl vom Client als auch vom Server sehr feingranular Direktiven darüber gesetzt werden können, ob und unter welchen Bedingungen eine Ressource gecached werden darf. Dieser Header ersetzt die beiden aus HTTP/1.0 bekannten Header und hat diese Form: Cache-Control: <cache-directive> Es können durchaus mehrere dieser Header in einer HTTP-Message enthalten sein. Ein Client hat u.a. folgende Cache-Direktiven zur Verfügung, um das Cache-Verhalten eines Proxy-Servers zu beeinflussen: no-cache: no-store: Hat die selbe Auswirkung wie der aus HTTP/1.0 bekannte Pragma-Header. Der Client wünscht auf jeden Fall eine aktuelle Version des angeforderten Dokuments. Damit wird ein Cache dazu angewiesen, weder Teile des Requests, noch Teile der darauf folgenden Response zu speichern. Dies kann z.b. geschehen, um sensible Daten davor zu bewahren, auf der Festplatte oder Backup-Tapes des Proxies oder gar als Inhalt einer Antwort an einen anderen Client wiedergefunden zu werden. 15

17 max-age=x: Damit besagt der Client, dass er eine Version eines Dokuments haben will, die weniger als x Sekunden alt ist. Hat ein Proxy eine jüngere Version gespeichert, kann er diese direkt ausliefern, ansonsten muss er vom Ursprungsserver eine aktualisierte Version anfordern. max-stale=x: Der Client ist sogar mit einer Version des Dokuments zufrieden, deren Gültigkeitszeitraum eigentlich schon abgelaufen ist. Jedoch sollte dieser nicht länger als x Sekunden abgelaufen sein. only-if-cached: Mit dieser Direktive weist der Client den Proxy an, dass er die angeforderte URL nur dann haben will, wenn der Proxy sie schon aus einem vorherigen Request gespeichert hat. Ein Proxy sollte im Falle dessen, dass er das Dokument nicht im Cache hat, mit dem Status-Code 504 (Gateway Timeout) antworten (siehe Abschnitt 2.2.2). Auch der Server kann Cache-Control-Header in seiner Antwort mitsenden, die das Verhalten von Proxies und Clients steuern. public: private: no-cache: no-store: Das in der Antwort enthaltene Dokument darf uneingeschränkt gecached werden, sowohl in öffentlichen Caches (Proxies) als auch in privaten (Browser-Cache). Die ausgelieferte Ressource ist nur für einen einzelnen Benutzer gedacht und darf daher in seinem privaten Browser-Cache gespeichert werden, jedoch nicht von zwischengeschalteten Proxies. Sowohl Proxies als auch Clients sollten diese Ressource nicht speichern, sondern sollten sie bei wiederholter Anforderung vom Ursprungsserver neuladen. Ähnlich zu no-cache, allerdings ist es hier clientseitigen History-Puffern erlaubt, die Antwort zu speichern. must-revalidate: Die ausgelieferte Ressource darf, sobald sie ungültig geworden ist, nicht mehr aus dem Cache verwendet werden. Dies gilt selbst dann, wenn ein Client darauf konfiguriert ist, Dokumente anzunehmen, deren Gültigkeit abgelaufen sind (siehe max-stale). proxy-revalidate: Ähnlich zu must-revalidate, gilt jedoch nicht für clientseitige, private Caches. max-age=x: Diese Direktive ist gleichbedeutend zum Expires-Header, ersetzt diesen in HTTP/1.1. Der Server gibt mit x die Anzahl der Sekunden an, nach dem die Gültigkeit der Ressource abläuft. s-maxage=x: Ähnlich zu max-age, jedoch nur für Proxies gültig. Ein Client kann diese Direktive ignorieren. 4 HTTP und Sicherheit Sicherheit ist ein immer wichtiger werdendes Thema im Internet, so auch bei HTTP. Zum einen ist es oftmals wünschenswert, eine Webseite nur einer eingeschränkten Nutzergruppe zugänglich ist, zum anderen möchte auch ein Benutzer sichergehen können, 16

18 dass die emfangenen Daten wirklich von dem Server kommen, den erwartete. Und zuletzt sollten vor allem sensible Daten auf dem Weg zwischen Client und Server sicher davor sein, von irgendwem auf dem Weg (bspw. Router, Proxies) ausgespäht zu werden. Zu diesem Zweck kann man sich bei HTTP verschiedener Mechanismen bedienen. 4.1 Zugriffsbeschränkung auf IP-Basis Eine Methode, um Webseiten nur bestimmten Nutzern zur Verfügung zu stellen, ist die Zugriffsbeschränkung auf Basis der IP-Adresse des Clients. Diese Methode ist relativ einfach und auch nicht auf HTTP beschränkt, sondern kann prinzipiell bei jedem Protokoll Anwendung finden. Jedoch birgt diese Methode auch Schwächen. Ziel einer Zugriffsbeschränkung ist ja meist die Einschränkung der Benutzergruppe, technisch realisiert wird hierbei jedoch eine Einschränkung der Adressen- bzw. Rechnergruppe, die auf die Ressource Zugriff hat. Man muss also sichergehen können, dass die Adressen, denen man den Zugriff erlaubt, nur von autorisierten Personen verwendet werden können. Dies mag im Firmen- oder Institutsnetz noch ausreichen, aber spätestens Nutzer eines Dialup-Zugangs bei einem großen Provider kann man hiermit nicht sicher erfassen. Desweiteren muss man aufpassen, dass im Bereich der freigeschalteten IP-Adressen sich kein Proxyserver befindet, der die eigentlich geheimen Daten dann doch wieder weltöffentlich zugänglich macht. 4.2 Authentication Eine weitere Art der Zugriffsbeschränkung ist die HTTP Authentication. Hierbei muss ein Nutzer einen Usernamen und ein Passwort eingeben, um Zugriff auf die Ressource zu erhalten. Damit kann man auch technisch eine Einschränkung auf Personenbasis vornehmen, ohne auf künstliche Abbildungen wie Adressbereiche zurückgreifen zu müssen. HTTP/1.1 definiert zwei Arten der Authentication, die sogenannte Basic Authentication und die Digest Authentication. Beide funktionieren generell ähnlich und sind sogenannte Challenge-Response-Verfahren: fordert ein Client eine zugriffsbeschränkte URL an, antwortet der Server zuerst mit einer 401 (Unauthorized)-Message. In dieser Message befindet sich ein weiterer Header in der folgenden Form: WWW-Authenticate: <challenge> Der Client muß darauf den gleichen Request noch einmal absenden, jedoch in einem weiteren Header die geforderte Antwort wie folgt mitsenden. Authorization: <response> Diese Response besteht bei der Basic Authentication im wesentlichen aus Username und Passwort. Die beiden derzeit standardisierten Verfahren sind in [5] genauer beschrieben. Die größte Schwachstelle der Basic Authentication ist, dass der Client bei jedem Request (also auch für jede Grafik im zugriffsbeschränkten Bereich) Username und Passwort mehr oder minder lesbar mitsendet. Die Gefahr, dass ein solches Passwort ausgespäht werden kann, ist sehr hoch. Aus diesem Grunde wurde die Digest Authentication entworfen, bei der Challenge und Response sich mit jedem Request ändern sind und von dritten nicht ohne größeren Aufwand zu entschlüsseln sind. 17

19 4.3 HTTPS HTTPS steht für Hypertext Transfer Protocol Secure sockets, dabei handelt es sich um HTTP über einen via einen Secure Socket Layer (SSL) gesicherten Kanal. Dadurch sind sämtliche Daten, die zwischen Client und Server ausgetauscht werden, verschlüsselt und für dritte nicht einsehbar. Desweiteren kann durch SSL sichergestellt werden, dass die beiden Verbindungspartner auch wirklich die sind, für die sie sich ausgeben. Die Verschlüsselung wird dabei in einer weiteren, im Prinzip transparenten Schicht durchgeführt. Darunter wird wiederum herkömmliches HTTP verwendet. Bei der Übertragung sensibler Daten via HTTP, angefangen beim Passwort bis hin zu Girokonto- oder Patientendaten sollte man grundsätzlich auf HTTPS zurückgreifen. 5 Zusammenfassung und Ausblick HTTP gehört mittlerweile zu den wichtigsten und am meisten benutzten Internetprotokollen. Dabei wurden über die Jahre auch neue Anwendungsbereiche erschlossen. Längst wird HTTP nicht mehr allein zur Abfrage von Dokumenten verwendet, sondern es gibt auch sogenannte Web-Anwendungen, die von der Suchmaschine über einen webbasierten -Client bis hin zum Internet-Banking oder Internet-Radio reichen. Wie bei vielen Internetprotokollen sah man auch bei HTTP mit der Zeit die Notwendigkeit, Ressourcen zu sparen und hat dem, wie in Abschnitt 3 geschildert, Rechnung getragen. Ähnliches gilt für Sicherheitsaspekte. Auch sind die Fähigkeiten der Clients stetig gewachsen, so dass Internet-Browser heutzutage viele Arten multimedialer Inhalte wiedergeben können. Oftmals jedoch geriet hierbei die Sicherheit ins Hintertreffen. So kommen immer wieder Sicherheitslücken in Browsern ins Gepräch, aber auch Sicher heitsfeatures wie z.b. die sogenannte Digest Authentication sind bis dato nur in wenigen Browsern implementiert. Mit der zunehmenden Kommerzialisierung des Internet und der Beliebtheit des Web-Browsers als Client für alles werden wahrscheinlich noch einige Erweiterungen folgen. Erste Ansätze dazu zeigen sich z.b. im schon reservierten Statuscode 402 (Payment Required), zu dem es noch keinen passenden Mechanismus zur Bezahlung über HTTP gibt. Ebenfalls ausbaufähig ist sicherlich die Content Negotiation, die schon in der derzeitig aktuellen Standardbeschreibung (siehe [1]) eher vage und unvollständig erscheint, in aktuellen Implementierungen jedoch noch unvollständiger ist. Und letzlich scheitert die Idee oftmals auch daran, dass ein Server gar keine verschiedenen Repräsentationen eines Dokuments zur Verfügung hat. 18

20 6 Abkürzungen CERN CSS HTML HTTP HTTPS IIS IP IW3C2 NCSA PC PNG RDF SOAP SSL URL W3C WWW XML Conseil Européen pour la Recherche Nucléaire Cascading Style Sheets Hypertext Markup Language Hypertext Transfer Protocol Hypertext Transfer Protocol Secure sockets Internet Information Server Internet Protocol International WWW Conference Committee National Center for Supercomputing Applications Personal Computer Portable Network Graphics Resource Description Framework Simple Object Access Protocol Secured Socket Layer Uniform Resource Locator Word Wide Web Consortium World Wide Web Extensible Markup Language Literatur [1] Hypertext Transfer Protocol HTTP/1.0 - (RFC 2616) [2] History of the Web - (http://public.web.cern.ch/public/achievements/web/history.html) [3] Standard for ARPA Internet Text Messages - (RFC 822) [4] Uniform Resource Locators (URL) - (RFC 1738) [5] HTTP Authentication: Basic and Digest Access Authentication - (RFC 2617) [6] de.comp.lang.php FAQ - (http://www.dclp-faq.de/) [7] Web Folders - (http://www.microsoft.com/, Windows 2000 Help) 19

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Bemerkung: Jede Ressource sollte über einen. Ressource A. Ressource. eindeutigen Namen verfügen. Ressource F. Ressource. Ressource E.

Bemerkung: Jede Ressource sollte über einen. Ressource A. Ressource. eindeutigen Namen verfügen. Ressource F. Ressource. Ressource E. 10 Hypertext Transfer Protocol 10.1 Hypermedia 10.2 Universal Resource Identifier 10.3 Nachrichten 10.4 Proxy 10.5 Cache 10.6 Authentifizierung 10.7 S Hypermedia: A D C B E F Bemerkung: Jede sollte über

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

HTTP Kommunikation (1)Request. HTTP - Überblick. HTTP Kommunikation (3) HTTP Kommunikation (2) Beispiel: Die folgende URL werde angefordert (Request)

HTTP Kommunikation (1)Request. HTTP - Überblick. HTTP Kommunikation (3) HTTP Kommunikation (2) Beispiel: Die folgende URL werde angefordert (Request) 15. Das Hypertext Transfer Protokoll 15-1 15. Das Hypertext Transfer Protokoll 15-2 HTTP - Überblick HTTP Kommunikation (1)Request 1. Requests und Responses 2. Content Negotiation 3. State Management (Cookies)

Mehr

HTTP. Hypertext Transfer Protocol. 4. Februar 2004

HTTP. Hypertext Transfer Protocol. 4. Februar 2004 HTTP Hypertext Transfer Protocol Bernhard Möller bmoeller@techfak.uni-bielefeld.de René Tünnermann rtuenner@techfak.uni-bielefeld.de 4. Februar 2004 1 Einleitung Das Hypertext Transfer Protokoll wird bereits

Mehr

Anwendungsprotokolle: HTTP, POP, SMTP

Anwendungsprotokolle: HTTP, POP, SMTP Anwendungsprotokolle: HTTP, POP, SMTP TCP? UDP? Socket? eingesetzt, um Webseiten zu übertragen Zustandslos Nutzt TCP Client schickt Anfrage ( HTTP-Request ) an Server, Server schickt daraufhin Antwort

Mehr

Themen. Anwendungsschicht DNS HTTP. Stefan Szalowski Rechnernetze Anwendungsschicht

Themen. Anwendungsschicht DNS HTTP. Stefan Szalowski Rechnernetze Anwendungsschicht Themen Anwendungsschicht DNS HTTP Anwendungsschicht OSI-Schicht 7, TCP/IP-Schicht 4 Dienste für den Nutzer/Anwender Unabhängig von den niederen Schichten Verschiedene Dienste bzw. Services DNS HTTP FTP,

Mehr

HTTP Hypertext Transfer Protocol

HTTP Hypertext Transfer Protocol Ein Vortrag aus der Reihe inf.misc 8. Juni 2005 50. Geburtstag von Tim Berners-Lee Inhalt 1 2 3 Content Negotiation Caching Authentifizierung 4 Definition RFC 2616, Abstract: The Hypertext Transfer Protocol

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

HTTP Squid Debugging-Hilfen Praxis. Der Webproxy Squid. Ein Überblick und ein wenig (viel) HTTP. Dirk Geschke. Linux User Group Erding

HTTP Squid Debugging-Hilfen Praxis. Der Webproxy Squid. Ein Überblick und ein wenig (viel) HTTP. Dirk Geschke. Linux User Group Erding Der Webproxy Ein Überblick und ein wenig (viel) HTTP Linux User Group Erding 28. April 2010 Gliederung HTTP 1 HTTP 2 3 4 HTTP Überblick HTTP Hypertext Transfer Protocol dient der Übertragung von Daten

Mehr

1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit

1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit XML- und Webservice- Sicherheit 1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol Gliederung Gliederung 1. HTTP 1.0 vs. 1.1 2. Verbindungen 3. HTTP-Methoden 4. Header 5. Ein Beispiel 6. Performance

Mehr

2 Grundlegende Funktionsweise eines HTTP-Servers

2 Grundlegende Funktionsweise eines HTTP-Servers 2 Grundlegende Funktionsweise eines HTTP-Servers In diesem Abschnitt soll das Zusammenspiel zwischen der Transportschicht und der Anwendungsschicht am Beispiel des Protokolls HTTP erläutert werden. Im

Mehr

180 Ringing Diese Antwort zeigt an, dass das aufgerufene Programm lokalisiert worden ist und der Anruf signalisiert wird.

180 Ringing Diese Antwort zeigt an, dass das aufgerufene Programm lokalisiert worden ist und der Anruf signalisiert wird. 1xx Informative Rückmeldungen 100 Trying Diese Antwort zeigt an, dass Maßnahmen im Namen des Anrufers ergriffen wurden, aber dass das aufgerufene Programm nicht lokalisiert wurde. 180 Ringing Diese Antwort

Mehr

PHP-Schwachstellen und deren Ausnutzung

PHP-Schwachstellen und deren Ausnutzung PHP-Schwachstellen und deren Ausnutzung 44. DFN Betriebstagung / 7. Februar 2006 DFN-CERT Services GmbH Jan Kohlrausch / CSIRT Gliederung Grundlagen HTTP und PHP Anatomie typischer Schwachstellen in PHP-Skripten

Mehr

Digitale Sprache und Video im Internet

Digitale Sprache und Video im Internet Digitale Sprache und Video im Internet Kapitel 6.4 SIP 1 SIP (1) SIP (Session Initiation Protocol), dient als reines Steuerungsprotokoll (RFC 3261-3265) für MM-Kommunikation Weiterentwicklung des MBONE-SIP.

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

XML- und Webservice- Sicherheit

XML- und Webservice- Sicherheit XML- und Webservice- Sicherheit 1. Das World Wide Web 1.3 Das Hypertext Transfer Protocol Gliederung Gliederung 1. HTTP 1.0 vs. 1.1 2. Verbindungen Literatur: A. S. Tanenbaum, Computer Networks, 4th. Ed.,

Mehr

Internet Protokolle für Multimedia - Anwendungen

Internet Protokolle für Multimedia - Anwendungen Internet Protokolle für Multimedia - Anwendungen Kapitel 5.7 Streaming im Web (RTSP) 1 Streaming Media (1) Streaming Media Strom ist kontinuierlich wird unmittelbar während des Empfangs wiedergegeben wird

Mehr

Basisinformationstechnologie I

Basisinformationstechnologie I Basisinformationstechnologie I Sommersemester 2013 24. April 2013 Rechnerkommunikation II Universität zu Köln. Historisch-Kulturwissenschaftliche Informationsverarbeitung Jan G. Wieners // jan.wieners@uni-koeln.de

Mehr

y Hypertext braucht Ressourcen-Identifikation y Unterschied zwischen Link und Identifier

y Hypertext braucht Ressourcen-Identifikation y Unterschied zwischen Link und Identifier +\SHUWH[W7UDQVIHU3URWRFRO +773 (ULN:LOGH 7,.² (7+= ULFK 6RPPHUVHPHVWHU hehuvlfkw y Hypertext braucht Ressourcen-Identifikation y Unterschied zwischen Link und Identifier y Universal Resource Identifier

Mehr

Modul 1.4.3. Grundlagen der Internettechnologien. von Günter Schoppe. Hannover, 2002. guenter.schoppe@ers-hameln.de

Modul 1.4.3. Grundlagen der Internettechnologien. von Günter Schoppe. Hannover, 2002. guenter.schoppe@ers-hameln.de Modul 1.4.3 Grundlagen der Internettechnologien von Günter Schoppe Hannover, 2002 guenter.schoppe@ers-hameln.de 1.4.3 Grundlagen der Internet-Technologien 1.4.3.1 Historie 1.4.3.2 Internetprotokolle 1.4.3.3

Mehr

Session Management und Cookies

Session Management und Cookies LMU - LFE Medieninformatik Blockvorlesung Web-Technologien Wintersemester 2005/2006 Session Management und Cookies Max Tafelmayer 1 Motivation HTTP ist ein zustandsloses Protokoll Je Seitenaufruf muss

Mehr

Peter Sobe Internettechnologien. HTTP Protokoll (1) Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xhtml) benutzt

Peter Sobe Internettechnologien. HTTP Protokoll (1) Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xhtml) benutzt WWW Web basierend auf dem Internet Das Internet war bereits eher als das Web vorhanden, mit verteilten Anwendungen, Dateitransfer, Netzwerk- Dateisystemen (NFS) Web: entstanden durch Vorhandensein des

Mehr

10 Caching. 10.1 Expirationsmodell

10 Caching. 10.1 Expirationsmodell 127 GET is one of the most optimized pieces of distributed systems plumbing in the world. Don Box, Webservices-Guru und SOAP-Miterfinder Die Unterstützung von Caching und das conditional GET sind zentrale

Mehr

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2)

Motivation. Inhalt. URI-Schemata (1) URI-Schemata (2) 14. URIs Uniform Resource Identifier 14-1 14. URIs Uniform Resource Identifier 14-2 Motivation Das WWW ist ein Hypermedia System. Es enthält: Resourcen (Multimedia Dokumente) Verweise (Links) zwischen

Mehr

REST Grundlagen. Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web. Olga Liskin

REST Grundlagen. Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web. Olga Liskin <olga.liskin@gmail.com> REST Grundlagen Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web Olga Liskin Übersicht Motivation, Einführung Architekturstil REST RESTful Webservices Patterns,

Mehr

Internet Protokolle Thema: HTTP Gruppenarbeit: Sören Kralemann Thorsten Kunze. Hypertext Transfer Protocol

Internet Protokolle Thema: HTTP Gruppenarbeit: Sören Kralemann Thorsten Kunze. Hypertext Transfer Protocol Einleitung Hypertext Transfer Protocol Was ist HTTP? Bei HTTP (HyperText Transfer Protocol) handelt es sich um ein einfaches Protokoll. Es ist seit 1990 in Gebrauch und bildet die Basis für das WWW (World

Mehr

Userhandbuch. Version B-1-0-2 M

Userhandbuch. Version B-1-0-2 M Userhandbuch Version B-1-0-2 M Inhaltsverzeichnis 1.0 Was bietet mir SERVRACK?... 3 1.1 Anmeldung... 3 1.2 Passwort vergessen?... 3 1.3 Einstellungen werden in Realtime übernommen... 4 2.0 Die SERVRACK

Mehr

3. Anwedungsprotokolle

3. Anwedungsprotokolle Überblick 3.1 Client/Server-Modell 3. Anwedungsprotokolle 3.2 Anforderung/Antwortprotokolle 3.3 Webkommunikation mit HTTP 3.4 E-mail Übertragung mit SMTP O. Kao Webbasierte Informationssysteme 3-1 3.1

Mehr

Mehrsprachige Web-Sites mit Apache

Mehrsprachige Web-Sites mit Apache Mehrsprachige Web-Sites mit Apache Content Negotiation statt Länderflaggen Stefan Kuhlins Lehrstuhl für Wirtschaftsinformatik III Universität Mannheim 68131 Mannheim http://www.kuhlins.de/ Zusammenfassung

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

CloudMatic V1.0. Inhalt

CloudMatic V1.0. Inhalt CloudMatic V1.0 Inhalt Einleitung... 2 CCUs hinzufügen... 3 meine-homematic.de... 4 Eigenes VPN... 4 View Editor... 5 Übersicht... 5 Allgemeine Einstellungen... 6 Kanäle hinzufügen... 6 Spezielle Kanäle...

Mehr

100 Trying Ein Anruf wird zu vermitteln versucht. Anruf wird weitergeleitet

100 Trying Ein Anruf wird zu vermitteln versucht. Anruf wird weitergeleitet Code Text Phrase Bedeutung 100 Trying Ein Anruf wird zu vermitteln versucht 180 Ringing Es klingelt beim Gegenüber 181 Call Is Being Forwarded Anruf wird weitergeleitet 182 Queued Anruf ist in Warteschleife

Mehr

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW

Secure Socket Layer (SSL) 1: Allgemeiner Überblick. Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Secure Socket Layer (SSL) Gilt für die Geräte: HL-4040CN HL-4050CDN HL-4070CDW DCP-9040CN DCP-9045CDN MFC-9440CN MFC-9840CDW Inhalt 1) Allgemeiner Überblick 2) Kurzer geschichtlicher Rückblick 3) Vorteile

Mehr

SMS-Gateway HTTP(S) Schnittstellenbeschreibung

SMS-Gateway HTTP(S) Schnittstellenbeschreibung SMS-Gateway HTTP(S) Schnittstellenbeschreibung Version 1.01 02.05.2013 Web: http://www.sms-expert.de Allgemeine Beschreibung der HTTP(S)- Schnittstelle des SMS-Gateways Inhaltsverzeichnis 1. Einleitung...

Mehr

Einleitung SMTP Grundlagen HTTP 1.1 Session Management in HTTP HTTP HTTP 0.9

Einleitung SMTP Grundlagen HTTP 1.1 Session Management in HTTP HTTP HTTP 0.9 HTTP 0.9 Die Urversion des Hypertext Transport Protocols bietet ein einfaches Request-Response Modell aufbauend auf einer TCP Verbindung. Client baut eine TCP Verbindung auf, der Default für den Zielport

Mehr

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

Mobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt

Mobilkommunikation. REST-basierte Dienste für verteilte, mobile Anwendungen. A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Mobilkommunikation REST-basierte Dienste für verteilte, mobile Anwendungen A. Gillert, A. Grebe, M. Hüffmeyer, C. Vogt Fachhochschule Köln, Institut für Nachrichtentechnik Fachhochschule Köln Anton Gillert,

Mehr

Konfigurieren eines Webservers

Konfigurieren eines Webservers Unterrichtseinheit 12: Konfigurieren eines Webservers Erleichterung der Organisation und des Verwaltens von Webinhalten im Intranet und Internet. Übersicht über IIS: Der IIS-Dienst arbeitet mit folgenden

Mehr

9RUOHVXQJDo 13.00-14.00 Uhr Hörsaal 2 EG 0006 3UDNWLNXP Do 14.00-16.00 Uhr PC-Labor U1075

9RUOHVXQJDo 13.00-14.00 Uhr Hörsaal 2 EG 0006 3UDNWLNXP Do 14.00-16.00 Uhr PC-Labor U1075 Praxis der Internet-Programmierung mit Java, Apache und XML (JAX) Institut für Informatik Martin.Guggisberg@unibas.ch KWWSMD[QDQRZRUOGRUJ -$9$ ;0/ $3$&+( Organisatorisches =HLWHQ" 9RUOHVXQJDo 13.00-14.00

Mehr

Handbuch ECDL 2003 Modul 7: Information Fachbegriffe

Handbuch ECDL 2003 Modul 7: Information Fachbegriffe Handbuch ECDL 2003 Modul 7: Information Fachbegriffe Dateiname: ecdl7_01_01_documentation.doc Speicherdatum: 29.11.2004 ECDL 2003 Modul 7 Information - Fachbegriffe Inhaltsverzeichnis 1 EINLEITUNG...

Mehr

email, Applikationen, Services Alexander Prosser

email, Applikationen, Services Alexander Prosser email, Applikationen, Services Alexander Prosser WWW für Menschen und Maschinen SEITE 2 (C) ALEXANDER PROSSER WWW für Menschen (1) Mensch gibt Adresse ein, z.b. evoting.at oder klickt Link an (2) Server

Mehr

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL TCP/IP: Standard Protokolle Konrad Rosenbaum, 2006/7 DNS - Domain Name System hierarchische, global verteilte Datenbank löst Namen in IP-Adressen auf Host hat einen primären Nameserver, der Fragen selbst

Mehr

Professionelles Webhosting

Professionelles Webhosting Professionelles Webhosting Basiswissen aus Sicht des Kunden Selbst die beste Webseite ist ohne einen funktionierenden Webserver nur eine Ansammlung nutzloser Files. Ausschlaggebend für diesen Vortrag Sehr

Mehr

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen ewon - Technical Note Nr. 005 Version 1.3 Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen 08.08.2006/SI Übersicht: 1. Thema 2. Benötigte Komponenten

Mehr

Apache. O'REILLY Beijing Cambridge Farnham Köln Paris Sebastopol Taipei Tokyo. Das umfassende Handbuch. Ben Laurie und Peter Laurie 2.

Apache. O'REILLY Beijing Cambridge Farnham Köln Paris Sebastopol Taipei Tokyo. Das umfassende Handbuch. Ben Laurie und Peter Laurie 2. 2.AUFLAGE Apache Das umfassende Handbuch Ben Laurie und Peter Laurie Deutsche Übersetzung von Peter Klicman, Jochen Wiedmann & Jörgen W. Lang O'REILLY Beijing Cambridge Farnham Köln Paris Sebastopol Taipei

Mehr

FTP HOWTO. zum Upload von Dateien auf Webserver. Stand: 01.01.2011

FTP HOWTO. zum Upload von Dateien auf Webserver. Stand: 01.01.2011 FTP HOWTO zum Upload von Dateien auf Webserver Stand: 01.01.2011 Copyright 2002 by manitu. Alle Rechte vorbehalten. Alle verwendeten Bezeichnungen dienen lediglich der Kennzeichnung und können z.t. eingetragene

Mehr

FilePanther Dokumentation. FilePanther. Benutzerhandbuch. Version 1.1 vom 14.02.2012 Marcel Scheitza

FilePanther Dokumentation. FilePanther. Benutzerhandbuch. Version 1.1 vom 14.02.2012 Marcel Scheitza FilePanther Dokumentation FilePanther Version 1.1 vom 14.02.2012 Marcel Scheitza Inhaltsverzeichnis 1 Verwaltung Ihrer Websites... 3 1.1 Verwaltung von Websites... 3 1.2 Verwaltung von Gruppen... 4 1.3

Mehr

FTP / WebDeploy / WebDAV. Handbuch

FTP / WebDeploy / WebDAV. Handbuch Handbuch August 2015, Copyright Webland AG 2015 Inhalt Einführung FTP WebDeploy WebDAV Anleitungen FTP Windows Mac WebDeploy Windows WebDAV Windows Mac Einführung FTP Haben Sie einen Zugang per FTP gewählt,

Mehr

HTTP / SHTTP. Schwerpunkt: Technische Aspekte. Ausarbeitung von Corinna Habets im Rahmen des Proseminars

HTTP / SHTTP. Schwerpunkt: Technische Aspekte. Ausarbeitung von Corinna Habets im Rahmen des Proseminars HTTP / SHTTP Schwerpunkt: Technische Aspekte Ausarbeitung von Corinna Habets im Rahmen des Proseminars Methoden und Werkzeuge an der RWTH Aachen im WS 2003/04 Stand: 16. Oktober 2003 Inhaltsverzeichnis

Mehr

Inhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17

Inhaltsverzeichnis. 2.1 Eine kurze Geschichte von REST... 9 2.2 Grundprinzipien... 11 2.3 Zusammenfassung... 17 xi 1 Einleitung 1 1.1 Warum REST?...................................... 1 1.1.1 Lose Kopplung................................ 2 1.1.2 Interoperabilität............................... 3 1.1.3 Wiederverwendung.............................

Mehr

KvBK: Basic Authentication, Digest Authentication, OAuth

KvBK: Basic Authentication, Digest Authentication, OAuth 14.07.2010 Julian Reisser Julian.Reisser@ce.stud.uni-erlangen.de KvBK: Basic Authentication, Digest Authentication, OAuth Motivation Authentifizierung Nachweis, dass man der ist für den man sich ausgibt

Mehr

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Einführung... 2-3 Servereinstellungen für die Einrichtung auf dem E-Mail Client... 4 E-Mail Adresse / Postfach einrichten...

Mehr

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken In diesem Tutorial zeigen wir Ihnen, wie Sie im Mozilla Thunderbird E-Mailclient ein POP3-Konto einrichten. Wir haben bei der Erstellung des Tutorials die Version 2.0.0.6 verwendet. Schritt 1: Auswahl

Mehr

SVV-GEMEINSCHAFTS-STATISTIKEN Statistik-Portal & Meldungen

SVV-GEMEINSCHAFTS-STATISTIKEN Statistik-Portal & Meldungen INHALTSVERZEICHNIS 1. Allgemeines... 2 2. Erste Inbetriebnahme... 2 2.1. Anmeldung... 2 2.2. JAVA-Runtime-Environment... 2 2.3. Spezielle Internet-Installationen bei den Versicherungen... 3 3. Kurz-Einführung

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Fernunterstützung mit Hilfe eines Virtual Network Computing Zugangs

Fernunterstützung mit Hilfe eines Virtual Network Computing Zugangs Fernunterstützung mit Hilfe eines Virtual Network Computing Zugangs V0.2 / 2008-2012 / Jens Gödeke Dieses Dokument wird gemäß der GNU Free Documentation License veröffentlicht. Diese Lizenzbedingungen

Mehr

HTTP, FTP, Telnet... diverse Kommunikations- Dienste 2 3 Internetschicht IP, ARP Ping. 3 4 Transportschicht TCP, UDP

HTTP, FTP, Telnet... diverse Kommunikations- Dienste 2 3 Internetschicht IP, ARP Ping. 3 4 Transportschicht TCP, UDP Alles zu Protokollen und Schichten TCP/IP- Schichten OSI- Schichten 4 6 + 7 Anwendungsschicht Bezeichnung Funktionen Dienste NetBIOS, WinSock 3 4 Transportschicht TCP, UDP HTTP, FTP, Telnet... diverse

Mehr

Emailprogramm HOWTO. zum Einrichten von Emailkonten in Outlook Express, Netscape Messenger, Eudora Email und Pegasus Mail

Emailprogramm HOWTO. zum Einrichten von Emailkonten in Outlook Express, Netscape Messenger, Eudora Email und Pegasus Mail Emailprogramm HOWTO zum Einrichten von Emailkonten in Outlook Express, Netscape Messenger, Eudora Email und Pegasus Mail Copyright 2003 by manitu. Alle Rechte vorbehalten. Alle verwendeten Bezeichnung

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Modul 123. E-Mail und FTP. Unit 6. E-Mail (pop / smtp), FTP (activ/passive Mode) FTP-Server mit Microsofts IIS

Modul 123. E-Mail und FTP. Unit 6. E-Mail (pop / smtp), FTP (activ/passive Mode) FTP-Server mit Microsofts IIS Modul 123 Unit 6 (V1.1) E-Mail und FTP Zielsetzung: E-Mail (pop / smtp), FTP (activ/passive Mode) FTP-Server mit Microsofts IIS Technische Berufschule Zürich IT Seite 1 Grundlagen : Das Store-and-Forward

Mehr

Installationsanleitung

Installationsanleitung Installationsanleitung POP3 und Bridge-Modus Inhaltsverzeichnis 1 POP3 und Bridge-Modus 2 1.1 Funktionsweise von POP3 mit REDDOXX 2 1.2 Betriebsarten 3 1.2.1 Standard-Modus 3 1.2.2 Bridge-Modus 6 1.2.3

Mehr

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle

ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle ZEUS Energiebuchhaltung Salzburg Automatische Zählerstandanlieferung: E-Mail-Schnittstelle Version: 1.0.0 Datum: 2013-11-20 Autor: Bernd Ennsfellner, Renate Pinggera gizmocraft, design and technology GmbH

Mehr

Apache HTTP Server Administration

Apache HTTP Server Administration Seminarunterlage Version: 11.04 Copyright Version 11.04 vom 9. Januar 2014 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Grundlagen DNS 1/5. DNS (Domain Name System)

Grundlagen DNS 1/5. DNS (Domain Name System) Grundlagen DNS 1/5 DNS (Domain Name System) Weltweit gibt es 13 zentrale DNS-Server (Root-Nameserver), auf denen die verschiedenen Domains abgelegt sind. Der Domönennamensraum bzw. das Domain Name Space

Mehr

Hypertext Transfer Protocol

Hypertext Transfer Protocol Hypertext Transfer Protocol Ausarbeitung und Präsentation Fach: Multimedia- und Webtechnologien Zeitraum: WS 2005 Präsentation: 10. Januar 2006 Von: Jens Franke Josef Jaschkowski Alex Miller Inhaltsverzeichniss

Mehr

VPN zum Miniserver mit Openvpn auf iphone/ipad und Synology NAS

VPN zum Miniserver mit Openvpn auf iphone/ipad und Synology NAS VPN zum Miniserver mit Openvpn auf iphone/ipad und Synology NAS Um den Zugriff auf den Miniserver aus dem Internet sicherer zu gestalten bietet sich eine VPN Verbindung an. Der Zugriff per https und Browser

Mehr

IT- und Medientechnik

IT- und Medientechnik IT- und Medientechnik Vorlesung 6: 14.11.2014 Wintersemester 2014/2015 h_da, Lehrbeauftragter Themenübersicht der Vorlesung Hard- und Software Hardware: CPU, Speicher, Bus, I/O,... Software: System-, Unterstützungs-,

Mehr

Internet Basics oder Wie funktioniert das Internet? Stefan Sporrer

Internet Basics oder Wie funktioniert das Internet? Stefan Sporrer Internet Basics oder Wie funktioniert das Internet? Stefan Sporrer Geschichte des Internets Geschichte des Internet 1967-1969: Entwicklung der Vernetzung von Computern (Advanced Research Projekt Agency

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen FAEL-Seminar Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte

Mehr

Web-Performance-Optimierung - Websites auf Speed SEO Barbecue - DIWISH - Kiel - 01. August 2012. Timo Heinrich t.heinrich@online-werbung.

Web-Performance-Optimierung - Websites auf Speed SEO Barbecue - DIWISH - Kiel - 01. August 2012. Timo Heinrich t.heinrich@online-werbung. SEO Barbecue Web-Performance-Optimierung - DIWISH - Kiel - 01. August 2012 - Websites auf Speed 1 2 Kinder 1 Frau 41 Jahre jung Seit 1996 autodidaktischer Onliner Schwerpunkte: Suchmaschinenoptimierung

Mehr

Angreifbarkeit von Webapplikationen

Angreifbarkeit von Webapplikationen Vortrag über die Risiken und möglichen Sicherheitslücken bei der Entwicklung datenbankgestützter, dynamischer Webseiten Gliederung: Einführung technische Grundlagen Strafbarkeit im Sinne des StGB populäre

Mehr

Verwendung der Support Webseite

Verwendung der Support Webseite amasol Dokumentation Verwendung der Support Webseite Autor: Michael Bauer, amasol AG Datum: 19.03.2015 Version: 3.2 amasol AG Campus Neue Balan Claudius-Keller-Straße 3 B 81669 München Telefon: +49 (0)89

Mehr

Vorlesung Werkzeuge der Informatik Grundlagen und Werkzeuge des WWW (Teil 1)

Vorlesung Werkzeuge der Informatik Grundlagen und Werkzeuge des WWW (Teil 1) Vorlesung Werkzeuge der Informatik Grundlagen und Werkzeuge des WWW (Teil 1) Jörg P. Müller Inhalt Entwicklung von Internet und WWW WWW-Architektur und Protokolle Web Ressourcen (oder: Was ist eine URL)

Mehr

Vorlesung Werkzeuge der Informatik Grundlagen und Werkzeuge des WWW (Teil 1)

Vorlesung Werkzeuge der Informatik Grundlagen und Werkzeuge des WWW (Teil 1) Vorlesung Werkzeuge der Informatik Grundlagen und Werkzeuge des WWW (Teil 1) Jörg P. Müller Inhalt Entwicklung von Internet und WWW WWW-Architektur und Protokolle Web Ressourcen (oder: Was ist eine URL)

Mehr

Einstieg Projektziel Proxy Grundlagen Demonstration Ausblick. Reverse Proxys. Robert Hilbrich. Fakultät für Informatik Humboldt Universität Berlin

Einstieg Projektziel Proxy Grundlagen Demonstration Ausblick. Reverse Proxys. Robert Hilbrich. Fakultät für Informatik Humboldt Universität Berlin Reverse Proxys Robert Hilbrich Fakultät für Informatik Humboldt Universität Berlin 28. September 2006 John von Neumann, 1949 It would appear that we have reached the limits of what it is possible to achieve

Mehr

Ich will raus! Tunnel durch die Firewall

Ich will raus! Tunnel durch die Firewall Ich will raus! Tunnel durch die Firewall Konstantin Agouros SLAC 07/Berlin Übersicht Wo ist das Problem? HTTPS SSH OpenVPN Skype/MSN ICMP DNS Alternativen zum Arbeiten draußen Wo ist das Problem? Viele

Mehr

Schnittstellenbeschreibung

Schnittstellenbeschreibung Schnittstellenbeschreibung Inhalt: - Beschreibung - Vorbereitungen - Die Details - Die verschiedenen Nachrichtenarten - Nachrichtenarchiv - Rückgabewerte - Schnellübersicht und Preisliste Weltweite-SMS.de

Mehr

Website Performance Optimierung

Website Performance Optimierung Website Performance Optimierung Fokus: Frontendoptimierung form4 GmbH & Co. KG Jan-Henrik Hempel Telefon: 030.278784-13 E-Mail: jan-henrik.hempel@form4.de Website Performance Optimierung Überblick 1 Relevanz

Mehr

KONFIGURATION DES MOZILLA E-MAIL CLIENT

KONFIGURATION DES MOZILLA E-MAIL CLIENT KONFIGURATION DES MOZILLA E-MAIL CLIENT Copyright 2004 by 2 ways - media & design, Inh. Lars Plessmann, Paulinenstr. 12, D-70178 Stuttgart. http://www.2-ways.de Lars.Plessmann@2-ways.de Der Mozilla Email

Mehr

E-Mail: BSCWMaster@dlz-it.de Tel.: +49 (3677) 669 2491 1. ALLGEMEINES ZU WEBDAV 1. 1.1 Vorteile 1. 1.2 Hinweise 2 2. WEBDAV MIT WINDOWS 7 3

E-Mail: BSCWMaster@dlz-it.de Tel.: +49 (3677) 669 2491 1. ALLGEMEINES ZU WEBDAV 1. 1.1 Vorteile 1. 1.2 Hinweise 2 2. WEBDAV MIT WINDOWS 7 3 WebDAV 1. ALLGEMEINES ZU WEBDAV 1 1.1 Vorteile 1 1.2 Hinweise 2 2. WEBDAV MIT WINDOWS 7 3 2.1 WebDAV Verbindung einrichten 3 2.1.1 1.Variante 3 2.1.2 2.Varainte 4 2.1.3 Netzwerkadresse hinzufügen 5 2.2

Mehr

1. Interface. Wireshark (Ehtereal)

1. Interface. Wireshark (Ehtereal) Wireshark (Ehtereal) Das Programm Wireshark Network Protocol Analyzer dient dazu, wie der Name schon sagt, ersichtlich zu machen, welche Datenpakete die Netzwerkkarte empfängt bzw. sendet. In Form von

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Microsoft ISA Server 2006

Microsoft ISA Server 2006 Microsoft ISA Server 2006 Leitfaden für Installation, Einrichtung und Wartung ISBN 3-446-40963-7 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40963-7 sowie im Buchhandel

Mehr

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

SWN-NetT Webmail. Benutzerhandbuch für SWN-NetT Webmail. SWN-NetT Webmail finden Sie unter: http://webmail.swn-nett.de

SWN-NetT Webmail. Benutzerhandbuch für SWN-NetT Webmail. SWN-NetT Webmail finden Sie unter: http://webmail.swn-nett.de SWN-NetT Webmail Benutzerhandbuch für SWN-NetT Webmail SWN-NetT Webmail finden Sie unter: http://webmail.swn-nett.de Übersicht Einstieg... 2 Menü... 2 E-Mail... 3 Funktionen... 4 Auf eine neue Nachricht

Mehr

easylearn Webservice lsessionservice Interface für Single Sign On (SSO)

easylearn Webservice lsessionservice Interface für Single Sign On (SSO) - 1 - easylearn Webservice lsessionservice Interface für Single Sign On (SSO) SDN AG, Solution Development Network Dezember 2008 - 2 - Inhaltsverzeichnis Inhaltsverzeichnis... 2 easylearn Webservice lsessionservice...

Mehr

LAMP HowTo (Linux Apache MySQL PHP) Zugriff per SSH auf den Server. Servername: gyko.no-ip.info (Lokal: 192.168.2.10)

LAMP HowTo (Linux Apache MySQL PHP) Zugriff per SSH auf den Server. Servername: gyko.no-ip.info (Lokal: 192.168.2.10) LAMP HowTo (Linux Apache MySQL PHP) Zugriff per SSH auf den Server Servername: gyko.no-ip.info (Lokal: 192.168.2.10) Stand: 04-2014 Warum Zugriff auf einen Server per SSH? Zunächst einmal möchte ich, dass

Mehr

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen

Grundlagen Funktionsweise Anhang Begriffserklärungen. DHCP Grundlagen. Andreas Hoster. 9. Februar 2008. Vortrag für den PC-Treff Böblingen 9. Februar 2008 Vortrag für den PC-Treff Böblingen Agenda 1 Einleitung Netzwerkeinstellungen 2 Feste Zuordnung Lease 3 4 Einleitung Einleitung Netzwerkeinstellungen DHCP, das Dynamic Host Configuration

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

ISA Server 2004 HTTP Filter - Von Marc Grote

ISA Server 2004 HTTP Filter - Von Marc Grote Seite 1 von 11 ISA Server 2004 HTTP Filter - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Einleitung In diesem Artikel erläutere ich die Konfiguration

Mehr

Rechnernetze I SS 2012. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 23.

Rechnernetze I SS 2012. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 23. echnernetze I SS 2012 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 23. März 2012 Betriebssysteme / verteilte Systeme echnernetze I (1/12) i echnernetze

Mehr

Express Import System

Express Import System Express Import System Anleitung für Empfänger TNT Express Import System Das Express Import System von TNT bietet Ihnen einen einfachen Weg zur Abholung von Dokumenten, Paketen oder Paletten in Ihrem Auftrag

Mehr

Collax Web Application

Collax Web Application Collax Web Application Howto In diesem Howto wird die Einrichtung des Collax Moduls Web Application auf einem Collax Platform Server anhand der LAMP Anwendung Joomla beschrieben. LAMP steht als Akronym

Mehr

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) Verbindungsorientiertes Protokoll, zuverlässig, paketvermittelt stream-orientiert bidirektional gehört zur Transportschicht, OSI-Layer 4 spezifiziert in RFC 793 Mobile

Mehr

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen

Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Aktuelle Sicherheitsprobleme im Internet: Angriffe auf Web-Applikationen Dr. Marc Rennhard Institut für angewandte Informationstechnologie Zürcher Hochschule Winterthur marc.rennhard@zhwin.ch Angriffspunkt

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr