2 Technische Grundlagen

Transkript

1 Seite 1 2 Technische Grundlagen 2 Technische Grundlagen 2.1 Identifikatoren im WWW 2.2 HTTP 2.3 Web-Architekturen 2.4 Proxy, Load-Balancing, CDNs

2 Seite 2 2 Technische Grundlagen 2.1 Identifikatoren Uniforme Identifikation Zentrale Idee des WWW: Informationsressourcen im Internet müssen weltweit eindeutig identifizierbar sein: Web-Ressourcen, FTP-Ressourcen, News-Ressourcen, Mailboxes, Directories, interaktive Dienste Identifikationsschema soll erweiterbar, vollständig und als String darstellbar sein. TBL: Universal Document Identifier (UDI) IETF: Uniform Resource Locator

3 Seite 3 2 Technische Grundlagen 2.1 Identifikatoren URI, URL, URN??? Sicht 1 [RFC3305 Classical View ]: Uniform Resource Identifier (URI) U. R. Locator (URL) U. R. Name (URN) Sicht 2 [RFC3305 Contemporary View ]: Uniform Resource Identifier (URI) Scheme Scheme Scheme Scheme

4 Seite 4 2 Technische Grundlagen 2.1 Identifikatoren Uniform Resource Identifier (URI) Syntax für alle Identifikatoren [RFC 2396] (inzwischen aktualisiert durch [RFC3986]) <uri> ::= <scheme>":"<scheme-specific-part> <scheme> bezeichnet Namensschema für diesen URI [ <scheme-specific-part> enthält aktuelle Identifikation entsprechend des <scheme>

5 Seite 5 2 Technische Grundlagen 2.1 Identifikatoren Uniform Resource Name (URN) Vereinheitlichung jeglicher Namensgebung URN [RFC1737,2141,2396,3406, 3986] (<scheme> ::= "urn") <urn> ::= "urn:" <nid> ":" <nss> nid = Namespace Identifier nss = Namespace Specific String Beispiele: urn:isbn: urn:fipa:language:acl urn:swift:type:fin$103

6 Seite 6 2 Technische Grundlagen 2.1 Identifikatoren URN Eigenschaften global eindeutig (global scope and uniqueness) dauerhaft beständig (persistence) Skalierbar unterstützt bestehende Applikationen Erweiterbar Unabhängig Auflösbar

7 Seite 7 2 Technische Grundlagen 2.1 Identifikatoren URN - Auflösung Infrastruktur für URNs z.zt. im experimentellen Stadium Dynamic Delegation Discovery System (DDDS) [RFC ] Dynamische String-Transformationsregeln aus Datenbank (z.b. DNS) konkrete Realisierungen Mapping E.164 Nummern auf SIP Endpoints Mapping URIs/URNs auf Resolver/Endpoints

8 Seite 8 2 Technische Grundlagen 2.1 Identifikatoren DDDS URI Mapping Example urn:foo: :annual-report-1997 lookup NAPTR records in DNS foo.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR "s" "foolink+i2l+i2c" "" foolink.udp.example.com. IN NAPTR "s" "rcds+i2c" "" rcds.udp.example.com. IN NAPTR "s" "thttp+i2l+i2c+i2r" "" thttp.tcp.example.com. lookup SRV records in DNS ;; Pref Weight Port Target rcds.udp.example.com IN SRV deffoo.example.com. IN SRV dbexample.com.au. IN SRV ukexample.com.uk. do an RCDS retrieval <ressource> Abkürzungen: NAPTR: Naming Authority PoinTeR [RFC3403] RCDS: Resource Cataloging and Distribution Service (see for details) SRV: Location of SeRVices [RFC 2782]

9 Seite 9 2 Technische Grundlagen 2.1 Identifikatoren Uniform Resource Locator (URL) Vereinheitlichung jeglicher Adressangabe URL scheme Definitionen [RFC1738,1808,2368,2396] z.b. http, https, ftp, news, nntp, mailto, telnet, ldap etc. scheme-specific-part Definitionen der generellen Form (vereinfacht): ["//"][user[":"password]"@"]host[":"port]["/"url-path] relative URLs sind möglich [RFC 1808]

10 Seite 10 2 Technische Grundlagen 2.1 Identifikatoren HTTP URL Einschränkung des generellen scheme-specific-part (vereinfacht) http_url = " host = hostname IP address port = *digit abs_path = "/"[path_segments][";" params] path_segments = segment *( "/" <segment> ) segment = *pchar *( ";" param )

11 Seite 11 2 Technische Grundlagen 2.1 Identifikatoren Beispiele ftp://fk4:passwd@ftp.uni-ulm.de/mydoc.pdf mailto:frank.kargl@uni-ulm.de cia://frank.kargl@de:12345/diary-agent urn:isbn:

12 Seite 12 2 Technische Grundlagen 2.1 Identifikatoren Vergleich URN vs. URL Eigenschaft URN URL Gültig global abs.url: global rel. URL: lokal global eindeutig ja abs. URL: ja rel. URL: nein Persistent ja nein Skalierbar ja ja Auflösung DDDS DNS/lokaler Server

13 Seite 13 2 Technische Grundlagen 2 Technische Grundlagen 2.1 Identifikatoren im WWW 2.2 HTTP 2.3 Web-Architekturen 2.4 Proxy, Load-Balancing, CDNs

14 Seite 14 Hypertext Transfer Protocol HTTP Setzt (i.d.r.) auf TCP/IP auf Einfaches Transferprotokoll idempotent zustandslos Client/Server, Request/Reply, Transaktionscharakter ASCII-kodiert 1. Öffne TCP Verbindung Client 2. Sende Request (URL) 3. Empfange Reply (Dokument) 4. Schließe TCP Verbindung Server

15 Seite 15 HTTP 0.9 Ursprüngliche Version von Tim Berners-Lee hypertext/hypertext/www/protocols/http.html hypertext/hypertext/www/protocols/http/asimplemented.html Implementierung kennt nur GET Methode Keine Formatvereinbarung o.ä. TCP-Verbindung wird sofort nach Übertragung des Dokuments geschlossen $ netcat webeng.informatik.uni-ulm.de 80 GET / <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <HEAD>...

16 Seite 16 HTTP 1.0 Informational RFC 1945 im Mai 1996 Verbesserungen: Strukturiertes Nachrichtenformat Weitere Requesttypen Aushandlung des Datenformats Basic Authentication GET /index.html HTTP/1.0 If-Modified-Since: Sat, 11 Oct :00:00 GMT <cr><lf> HTTP/ OK Date: Sat, 11 Oct :09:53 GMT Server: Apache/ (Unix) Content-Type: text/html <cr><lf> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">...

17 Seite 17 Schwachstellen von HTTP 1.0 Keine Unterstützung für non-ip-based virtual hosts d.h. mehrere Web Server laufen auf einer Maschine mit einer IP-Adresse Pro Request eine Verbindung harmoniert schlecht mit TCP Eigenschaften Primitives Caching Modell fehlende Unterstützung für Proxies und Gateways Kein partieller Transfer von Ressourcen Fehler führen zur vollständigen Retransmission Unsichere Authentisierung Passwort im Klartext

18 Seite 18 HTTP 1.1 RFC 2068 (Jan. 97), RFC 2616 (Juni 99) Verbesserungen Performance persistente Verbindungen Pipelining Caching Cachekontrolle Proxy-Authentifizierung Diverses Byte Range Operation Fragmentierte Nachrichten Content Negotiation Cookies Digest-Authentication

19 Seite 19 HTTP 1.1 RFC 2616 Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 [33].

20 Seite 20 HTTP 1.1 Überblick Protokoll auf Applikationsebene Für verteilte, kooperativ genutzte Hypermediainformationsysteme. Eigenschaften: generisch zustandslos objekt-orientiert offen unterstützt Typisierung von Daten unterstützt Verhandlung über Datenrepräsentationen unabhängig von den übertragenen Daten

21 Seite 21 HTTP 1.1 Beispiel Request GET /index.html HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.4) Gecko/ Accept: application/x-shockwave-flash,text/xml,application/xml, application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8, video/xmng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Max-Forwards: 10 Proxy-Connection: keep-alive <cr><lf> <cr><lf>: Zeilentrenner; Carriage Return Line Feed Leerzeile

22 Seite 22 HTTP 1.1 Beispiel Response HTTP/ OK Date: Wed, 22 Oct :46:17 GMT Server: Apache/ dev (Unix) Accept-Ranges: bytes Cache-Control: max-age=86400 Expires: Thu, 23 Oct :47:31 GMT Content-Length: Content-Type: text/html; charset=iso Via: 1.1 scuba.informatik.uni-ulm.de (Apache/2.0.46) <cr><lf> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <cr><lf>: Zeilentrenner; Carriage Return Line Feed Leerzeile

23 Seite 23 HTTP Request/Response Client (Browser) Server Benutzer Analyse der Seite Request Response Ressource laden Transaktion 1 Request Response Ressource laden Transaktion 2

24 Seite 24 HTTP Nachrichtenaufbau HTTP Request Request Methode Request Header HTTP Response Response Status Response Header <cr><lf> [Body] <cr><lf> [Body]

25 Seite 25 HTTP Request Format: <Method> <Request URI> <HTTP version> Request Methoden GET* fragt Ressource an HEAD* fragt nur Header einer Ressource an OPTIONS liefert Inform. zur Kommunikationskette POST Request mit Übertragung von Parametern PUT Übertragen einer Ressource zum Server DELETE Löschen einer Ressource auf Server TRACE Server liefert Request zurück an Client CONNECT Verbindungsaufbau SSL Tunnel * muss implementiert sein

26 Seite 26 HTTP GET Request Syntax: GET <URI> <VERSION> Anfragen der im URI angegebenen Ressource Statische Ressource Dynamische Ressource Übergabe von Parametern Conditional GET Holt die Ressource nur wenn Bedingung erfüllt ist Spart gegebenenfalls Netzwerkverkehr Partial GET Holt nur einen Teil der Ressource Spart gegebenenfalls Netzwerkverkehr

27 Seite 27 HTTP GET Beispiel GET /index.html HTTP/1.1 Host: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.4) Gecko/ Keep-Alive: 300 <cr><lf> HTTP/ OK Date: Wed, 22 Oct :46:17 GMT Server: Apache/ dev (Unix) Accept-Ranges: bytes Content-Length: Content-Type: text/html; charset=iso <cr><lf> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "

28 Seite 28 HTTP Conditional GET Syntax: GET <URI> <VERSION> <CONDITIONAL-HEADER>: <CONDITION> z.b. If-Modified-Since, If-Match, If-Range, etc. GET / HTTP/1.1 Host: shark.informatik.uni-ulm.de If-Modified-Since: Wed, 22 Oct :00:00 GMT <cr><lf> HTTP/ Not Modified Date: Wed, 22 Oct :03:24 GMT Server: Apache/ (Linux/SuSE)

29 Seite 29 Partial GET Syntax: GET <URI> <VERSION> Range: <RANGE> z.b. bytes=0-499 die ersten 500 Byte der Ressource bytes=-100 die letzten 100 Byte der Ressource bytes=1500- der Rest der Ressource (ab 1500) GET / HTTP/1.1 Range: bytes=0-79 <cr><lf> HTTP/ Partial Content Date: Wed, 22 Oct :10:37 GMT Last-Modified: Fri, 04 May :01:18 GMT Accept-Ranges: bytes Content-Length: 80 Content-Range: bytes 0-79/1456 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

30 Seite 30 HTTP HEAD Request Syntax: HEAD <URI> <VERSION> Anfragen der Header-Information für die im URI angegebene Ressource Liefert gleiche Header-Information wie GET Anfrage der Meta-Information Anwendung Testen von Hyperlinks Überprüfen ob Anfrage notwendig spart gegebenenfalls Netzwerkverkehr

31 Seite 31 HTTP HEAD Request HEAD / HTTP/1.1 Host: shark.informatik.uni-ulm.de <cr><lf> HTTP/ OK Date: Wed, 22 Oct :18:01 GMT Server: Apache/ (Linux/SuSE) Last-Modified: Fri, 04 May :01:18 GMT Accept-Ranges: bytes Content-Length: 1456 Content-Type: text/html; charset=iso Content-Language: en

32 Seite 32 HTTP OPTIONS Request Syntax: OPTIONS <URI> <VERSION> Abfrage der Kommunikationsoptionen für eine Ressource oder den Server (<URI>=*) Headers in Response Accept Accept-Range Accept-* Public Allow (entity)

33 Seite 33 HTTP OPTIONS Beispiel I OPTIONS * HTTP/1.1 Host: <cr><lf> HTTP/ OK Date: Wed, 22 Oct :27:02 GMT Server: Apache/ dev (Unix) Allow: GET,HEAD,POST,OPTIONS,TRACE Cache-Control: max-age=86400 Expires: Thu, 23 Oct :27:02 GMT Content-Length: 0 Content-Type: text/plain; charset=iso

34 Seite 34 HTTP OPTIONS Beispiel II OPTIONS * HTTP/1.1 Host: <cr><lf> HTTP/ OK Server: Microsoft-IIS/5.0 Date: Wed, 22 Oct :43:09 GMT Content-Length: 0 Accept-Ranges: bytes DASL: <DAV:sql> DAV: 1, 2 Public: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Allow: OPTIONS, TRACE, GET, HEAD, DELETE, PUT, POST, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, SEARCH Cache-Control: private

35 Seite 35 HTTP POST Request Syntax: POST <URI> <VERSION> <HEADER> <cr><lf> <MESSAGE-BODY> Übergeben von Daten an eine Ressource siehe CGI & Co.

36 Seite 36 HTTP POST Beispiel POST /cgi-bin/anmeldung.pl HTTP/1.1 Host: Content-Type: application/x-www-form-urlencoded Content-Length: 146 <cr><lf> Vorname=Frank&Name=Kargl&Strasse=Albert-Einstein-Allee+11& PLZ=89081&Ort=Ulm&Telefon=%2B & Fax=%2B &Mail=frank%40kargl.net HTTP/ OK Date: Wed, 22 Oct :59:27 GMT Server: Apache/ (Linux/SuSE) Content-Type: text/html <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "

37 Seite 37 HTTP TRACE Request Syntax: TRACE <URI> <VERSION> Eingeschränkt durch <Max-Forwards> Zur Diagnose der Kommunikation Zeigt den Weg der Nachricht Header-Feld: VIA Die gesendete Nachricht im Message-Body

38 Seite 38 HTTP TRACE Max Forwards I TRACE /index.htm HTTP/1.1 Host: Max-Forwards: 0 <CRLF> HTTP/ OK Server: Squid/2.2.STABLE3 Mime-Version: 1.0 Date: Thu, 28 Oct :02:04 GMT Content-Type: text/plain Content-Length: 66 Expires: Thu, 28 Oct :02:04 GMT X-Cache: MISS from Proxy-Connection: close TRACE /index.htm HTTP/1.1 Host: Max-Forwards: 0

39 Seite 39 HTTP TRACE Max Forwards II TRACE /index.htm HTTP/1.1 Host: Max-Forwards: 2 <CRLF> HTTP/ OK Server: Microsoft-IIS/5.0 Date: Wed, 27 Oct :11:58 GMT Content-Type: message/http Content-Length: 192 Age: 0 X-Cache: MISS from Proxy-Connection: keep-alive TRACE / HTTP/1.0 Host: Via: (Squid/2.2.S3) X-Forwarded-For: Cache-Control: max-age= Connection: keep-alive

40 Seite 40 HTTP TRACE Beispiel I ohne Proxy TRACE / HTTP/1.1 Host: <CRLF> HTTP/ OK Server: Microsoft-IIS/4.0 Date: Wed, 27 Oct :09:29 GMT Content-Type: message/http Content-Length: 42 TRACE / HTTP/1.1 Host:

41 Seite 41 HTTP TRACE Beispiel II mit Proxy TRACE HTTP/1.1 Host: <CRLF> HTTP/ OK Server: Microsoft-IIS/5.0 Date: Wed, 27 Oct :11:58 GMT Content-Type: message/http Content-Length: 192 Age: 0 X-Cache: MISS from Proxy-Connection: keep-alive TRACE / HTTP/1.0 Host: Via: (Squid/2.2.S3) X-Forwarded-For: Cache-Control: max-age= Connection: keep-alive

42 Seite 42 HTTP Nachrichtenaufbau HTTP Request Request Methode Request Header HTTP Response Response Status Response Header <cr><lf> [Body] <cr><lf> [Body]

43 Seite 43 Request/Response Header Besteht aus General Header Request/Response Header Entity Header General Header: Date Datum Pragma no-cache; kein Caching Cache-Control Caching Ansteuerung Connection persistente Verbindung? Trailer weitere Header am Ende Transfer-Encoding Body-Transformation Upgrade Liste zusätzlicher Protokolle Via Liste von Proxies Warning Warnungs Code

44 Seite 44 Request Header Authorization* From* If-Modified-Since* Referer* User-Agent* Host Accept/Accept-Charset/ Accept-Encoding/-Language Expect Range If-Range/-Match/-None-Match/ If-Unmodified-Since Max-Forwards Proxy-Authorization TE (Transfer-Extension) Cookie/Cookie2 SOAPAction Client Autorisierung Adresse Benutzer nur senden, wenn modifiziert URI der vorhergeh. Ressource Information über Client-SW Hostname des Webservers Akzeptierte Medien / Zeichensätze Kodierung / Sprache Erwartete Server Reaktion angeforderter Content Teil Bedingungen für Auslieferung Maximale Zahl Proxies Autorisierung für Proxy Akzeptierte Transfer Enc. im Reply Angabe von Cookies Angabe der SOAP Aktion * auch bei HTTP/1.0

45 Seite 45 Response Header Location* Server* WWW-Authenticate* Accept-Ranges Age ETag (Entity-Tag) Proxy-Authenticate Retry-After Vary Set-Cookie/Set-Cookie2 Ressource an anderer Lokation Information über Server-SW Autorisierung notwendig Angaben zu Range-Req. Alter der Response Identifikation der Ressource Autorisierung für Proxy Neuer Zugriffsversuch Hinweis für Proxy zur Auswahl des Content Setzen von Cookies * auch bei HTTP/1.0

46 Seite 46 Entity Header Allow* Content-Encoding* Content-Length* Content-Type* Content-Language Content-Location Content-MD5 Content-Range Expires* Last-Modified* Unterstützte Request-Typen Content Kodierung Content Länge Content Typ Content Sprache URI der Ressource Prüfsumme der Ressource Übertragener Bereich wann wird Content ungültig? wann wurde Content modifiziert? * auch bei HTTP/1.0

47 Seite 47 HTTP Response Codes 5 Gruppen von Codes Informational: 1xx Weitere Bearbeitung des Requests z.b. 100 Continue, 101 Switching Protocols Success: 2xx Request erfolgreich empfangen und verarbeitet z.b. 200 OK, 204 No Content Redirection: 3xx Weitere Aktionen nötig z.b. 301 Moved Permanently, 304 Not Modified Client Error: 4xx Request enthält Fehler oder kann nicht ausgeführt werden z.b. 403 Forbidden, 405 Method not Allowed Server Error: 5xx Server nicht in der Lage, gültigen Req. auszuführen z.b. 500 Internal Server Error, 505 HTTP Version not supported

48 Seite 48 HTTP persistente Verbindungen Header Field Connection Werte: Keep-Alive, Close Weniger Betriebssystem-Ressourcen Weniger Transportpakete Pipelining möglich Reihenfolge muss vom Server gewahrt werden

49 Seite 49 HTTP persistente Verbindungen Open TCP URL Analyse Bild 1 Bild 2 Client (Browser) Request Response Request Response Request Response Server Ressource laden (HTML) Ressource laden Ressource laden Bild n Close TCP Request Response Ressource laden

50 Seite 50 HTTP Pipelining Open TCP Client Server GET /index.html Verbindung akzeptieren Daten schicken index.html GET /logo.gif GET /back.jpg GET /people.pl Daten schicken logo.gif Daten schicken back.jpg Daten schicken people.pl Close TCP Socket schließen

51 Seite 51 HTTP Pipelining Beispiel GET / HTTP/1.1 Host: medien.informatik.uni-ulm.de Connection: keep-alive GET /images/logo.gif HTTP/1.1 Host: medien.informatik.uni-ulm.de Connection: keep-alive GET /cgi-bin/people.pl HTTP/1.1 Host: Connection: close Datei: index.html Datei: logo.gif Datei: people.pl HTTP/ OK Date: HTTP/1.1 Tue, Oct OK :56:37 GMT Server: Date: HTTP/1.1 Apache/1.2.1 Tue, Oct OK :56:37 GMT Keep-Alive: Server: Date: Apache/1.2.1 Tue, timeout=10, 26 Oct 1999 max=100 16:56:37 GMT Connection: Last-Modified: Server: Keep-Alive Apache/1.2.1 Fri, 08 Aug :18:43 GMT Transfer-Encoding: Content-Length: Connection: close 2044 chunked Content-Type: Keep-Alive: Transfer-Encoding: text/html timeout=10, chunked max=99 Connection: Content-Type: Keep-Alive text/html f3fcontent-type: image/gif <html><head> cd2 <title>multimedia GIF89ax <html><head> H ÕÿÿÀ Computing</title> <title>mi - People</title>...

52 Seite 52 HTTP Access Authentication Ziel Autorisierter Zugang zu Ressourcen Protokollieren der Benutzer (Namen) die zugreifen Varianten [RFC 2617]: Basic Access Authentication Einfaches Username - Password Schema <user>:<passwd> Base64 kodiert Keine Verschlüsselung! Digest Access Authentication Challenge Response Verfahren Keine Übertragung des Passworts im Klartext

53 Seite 53 HTTP Access Authentication Ablauf Senden eines HTTP Requests Response mit Status-code 401 Unauthorized und Header WWW-Authenticate Erneuter Request mit zusätzlichem Header Authorization: <user>:<passwd> (Base64 kodiert) Überprüfen von <user>:<passwd> beim Server Rückgabe des Dokuments

54 Seite 54 HTTP Basic Authentication Client Server Request: /something Benutzer:Passwort (Base64 kodiert) GET /something HTTP/1.1 HTTP/ Unauthorized WWW-Authenticate: Basic realm="private Area" Anonymer Zugriff? Nein Anzeige der Daten GET /something HTTP/1.1 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== HTTP/ OK Daten... Benutzer + Passwort prüfen

55 Seite 55 Beispiel Access Authentication Datei.htaccess Satisfy all AuthType Basic AuthName "Private Area" Require user frank AuthUserFile /etc/httpd/.htpasswd Order deny,allow Allow from all Datei.htpasswd # frank:test frank:tpalntyn7sijs

56 Seite 56 Beispiel Access Authentication Request GET /private/ HTTP/1.1 Host: medien.informatik.uni-ulm.de Accept-Language: de User-Agent: Mozilla/4.0 Response HTTP/ Unauthorized Server: Apache/ (Linux/SuSE) WWW-Authenticate: Basic realm="private Area" Content-Length: 24 Content-Type: text/html Error: Access is Denied Request Method Header Leerzeile Status Header Leerzeile Nutzdaten

57 Seite 57 Beispiel Access Authentication Browser fragt den Benutzer nach dem Benutzername und Passwort Gegebenenfalls hat der Browser Benutzername und Passwort von einem vorigen Zugriff gespeichert

58 Seite 58 Beispiel Access Authentication Request GET /private/ HTTP/1.1 Host: medien.informatik.uni-ulm.de Accept-Language: de User-Agent: Mozilla/4.0 Authorization: Basic ZnJhbms6dGVzdA== base64(frank:test) Request Method Header Leerzeile Response HTTP/ OK Server: Apache/ (Linux/SuSE) Content-Length: 592 Content-Type: text/html <html><head>... Status Header Leerzeile Nutzdaten

59 Seite 59 HTTP Digest Authentication Digest Authentication Response HTTP/ Unauthorized WWW-Authenticate: Digest realm="webengineering Testinstallation", nonce="7aejfthkawa=57e4252a2c68c0f9d30b0699f9b7de79d7895e1b", algorithm=md5, qop="auth" Request Authorization: Digest username="hugo", realm="webengineering Testinstallation", nonce="7aejfthkawa=57e4252a2c68c0f9d30b0699f9b7de79d7895e1b", uri="/", algorithm=md5, response="e6f59508c24c4893b1acadf b9", qop=auth, nc= , cnonce="e e8bdaee1" Analog Proxy Authentication (Basic/Digest) Header Proxy-Authenticate und Proxy-Authorization

60 Seite 60 HTTP Digest Authentication Digest Authentication nonce: Zufallswert, vom Server vorgegeben, muss vom Client unverändert mit jeder Seitenanfrage für das entsprechende Realm gesendet werden qop: Quality of Protection, Wahl des Schutzes (Digest auth, oder zusätzl. Content protection) (optional) cnonce: Client Nonce, nötig wenn qop gesetzt nc: Nounce-count, nötig bei qop, Anzahl der Requests, die Client in Auth.session gesendet hat (Erkennung von Replays, nötig für Request-Digest) response: KeyedDigest(secret,data) = Hash(concat(secret,data)) z.b. mit Hashfunktion MD5, ohne qop (einfachster Fall): response = MD5(Hash(username+ : +realm+ : +password)+nonce+ : + digest (Method)+Anfrage-URI) Warum nochmals Hash(username,...)?

61 Seite 61 Partieller Transfer von Ressourcen Partial GET Spezifiziert durch das Headerfeld Range: <RANGE> Übertragung sehr großer Dateien in einzelnen Blöcken Wiederholung von abgebrochen Übertragungen es muss nur der Teil übertragen werden der fehlt Parallele Übertragung von Teilen einer großen Datei Beispiel: Request GET /large.zip HTTP/1.1 Host: Range: bytes= GET /large.zip HTTP/1.1 Host: Range: bytes= Response (partial) large.zip( bytes) large.zip( bytes) Response (complete) large.zip

62 Seite 62 Chunked Encoding Chunked Encoding für dynamische Ressourcen Sequenz von <Chunk Size, Chunk Data> Paaren Header Field: Transfer-Encoding Beispiel HTTP-Header chunk size chunk data chunk size chunk data... 0 size HTTP/ OK Date: Tue, 26 Oct :56:37 GMT Server: Apache/1.2.1 Transfer-Encoding: chunked Content-Type: text/html f3f <html><head> <title>medieninformatik</title>... <td width=40> </td> 952 <td valign="top">... </body></html> 0...

63 Seite 63 Content-Negotiation Auswahl Sprachspezifischer Ressourcen Ressourcen unterschiedlicher Qualität Ressourcen unterschiedlicher Kodierung Header Fields wie z.b.: Accept, Accept-Charset, Accept-Language, Accept- Encoding, User-Agent, Konzepte: Server-driven, Agent-driven, Transparent

64 Seite 64 Content-Negotiation Server-driven auf Grund der Anfrage wird die passende Ressource geliefert Probleme: Server kennt Wünsche des Users nicht, unnötige Headerinfo, komplizierter Server, Caching von Inhalten Agent-Driven Server schickt eine Auswahlliste, Browser/User entscheidet 300 (multiple choices) Probleme: Zweiter Request, Userauswahl? Transparent Proxy bekommt Auswahl (Agent-driven) und wählt für Client aus (Server-driven)

65 Seite 65 Weitere Headerfelder I User-Agent Enthält Informationen über Browser und ggf. Betriebssystem des Benutzers Kann für Content-Negotiation verwendet werden Für statistische Zwecke (wichtige für die Erstellung von Seiten, was kann man voraussetzen) z.b. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-us; rv:1.4)gecko/ User-Agent: amaya/v2.2 libwww/5.2.8 Server Enthält Informationen über Server und ggf. Betriebssystem Richtige und genaue Angaben sind evtl. Sicherheitsrisiko z.b. Server: Apache/ (Unix) ApacheJServ/1.0 PHP/3.0.6 Server: Microsoft-IIS/5.0

66 Seite 66 Weitere Headerfelder II Referer Enthält die Informationen über die URL der zuletzt besuchten Seite Wird i.a. vom Browser nur mitgeschickt, wenn der URL durch Anklicken eines Links angewählt wurde Verwendung: Sicherstellen, dass eine Funktion bzw. eine Seite nur von einer bestimmten vorgegebenen Adresse aus aufgerufen wird. Nachvollziehen woher Benutzer auf die eigene Seite kommen z.b. Feststellen welche Werbung sich lohnt z.b. Referer: lehre/current/webeng_ws0304/index.xml

67 Seite 67 Server-initiierte Kommunikation HTTP ist ein Request-Reply Protokoll Anfragen gehen immer vom Client aus Server kann keine Kommunikation zum Client aufbauen Lösung: Client muss die Information periodisch nachfragen Problem: Skalierbarkeit Standard-Browser Alle 60 Sekunden Seite erneut laden: <META HTTP-EQUIV= "Refresh" content="60"> Umleiten auf URL: <META HTTP-EQUIV= "Refresh" content="0; URL= Dauerhaft persistente Verbindung Problem: Ressourcenbelegung beim Server

68 Seite 68 Cookies HTTP ist zustandslos es besteht kein Zusammenhang zwischen zwei Anfragen Lösungen: Cookies oder URL-Rewriting Durch die Verwendung von Cookies wird der Zustand beim Client gespeichert Netscape: RFC 2965 Header Set-Cookie(2) Response Header (wird vom Server zum Client geschickt) Cookie(2) Request Header (wird vom Client zum Server geschickt) abhängig von der Domain und dem aktuellen Pfad Verwendung in CGI, PHP, etc. Siehe 4. Kapitel

69 Seite 69 Cookies Beispiel I GET / HTTP/1.1 Host: <CRLF> HTTP/ OK Date: Tue, 28 Oct :17:15 GMT Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) mod_fastcgi/ Set-Cookie: session-id-time= ; path=/; domain=.amazon.de; expires=monday, 03-Nov :00:00 GMT Set-Cookie: session-id= ; path=/; domain=.amazon.de; expires=monday, 03-Nov :00:00 GMT Location: Connection: close Content-Type: text/html [... ]

70 Seite 70 Cookies Beispiel II GET / HTTP/1.1 Host: Cookie: session-id-time= ; session-id= HTTP/ OK [... ]

71 Seite 71 Kommunikation mit Cookies Client Server/Applikation Request Response + Set-Cookie Erstelle Cookie Request + Cookie Response Verwende Cookie Request + Cookie Response Verwende Cookie

72 Seite 72 2 Technische Grundlagen 2 Technische Grundlagen 2.1 Identifikatoren im WWW 2.2 HTTP 2.3 Web-Architekturen 2.4 Proxy, Load-Balancing, CDNs

73 Seite 73 Webbasiertes Client-Server Modell Web-Adresse Web-Dienst Response Request Web-Protokoll Web-Client Browser Web-Ressource Web-Server Datenquelle

74 Seite 74 Wichtige Begriffe Web-Client Unterstützt Präsentation von Web-Content Meist Browser Web-Server Verwaltet Web-Content Liefert Web-Ressourcen an Web-Client Web-Dienst Transport- und Anwendungsinfrastruktur zum Transport von Web-Content vom Web-Server zum Web-Client Web-Protokoll Kommunikationsprotokoll der Anwendungsschicht Z.B. HTTP, FTP, SMTP etc. Web-Ressource Einzelnes Datenobjekt, welches der Web-Server an den Web-Client liefert Wird mit URI adressiert Web-Content Sammelbegriff für Web-Ressourcen Statischer vs. dynamisch erzeugter Content

75 Seite 75 Grundaufbau Web-Browser Ausgabe (Bildschirm) Wiedergabe-Instanz Layout DOM Plug-Ins Interpreter Java Flash HTML XML Eingabe (Maus/Tastatur) MIME-Handler Controller HTTP FTP Protokoll- Instanzen Komm.-Softwareschnittstelle Web-Dienst

76 Seite 76 Client-Konzepte Browser Textbasierte Browser (lynx) Grafischer Browser (Mozilla) Audio-Browser (IBM Homepage Reader) Micro-Browser (WAP-Browser) Sonstige Clients Eingebettet in Software (Virenscanner) Web-Clients in Embedded Systems

77 Seite 77 Klassen von Webservern Server für statischen Content Statischer Webserver Server für dynamischen Content Dynamischer Webserver Webserver mit verteilter Contentverarbeitung Verteilte Anwendungen Web als Basis für Middleware zur Anwendungsintegration

78 Seite 78 Grundaufbau statischer Webserver Betriebssystem Kern Virtuelles Dateisystem Webserver Konfig. Datei Authentisierung etc n HTTP HTTPS Client- Tasks Protokoll- Instanzen Komm.-Softwareschnittstelle Web-Dienst

79 Seite 79 Virtual Hosts Auf einem Rechner (mit einem Netzwerkinterface) sollen verschiedene Domains zur Verfügung stehen Ein oder mehrere Webserver (Software) sollen die Anfragen, für die auf dem Rechner vorhandenen Domains, beantworten Typische Anwendung: Web-Hosting (Provider) Internet Netzkarte Webspace-Provider Rechner: host.provider.de /firma-a.com /firma-b.org /firma-c.net /firma-xyz.de