Hyptertext Transfer Protocol (HTTP)
Begriffe
- Server: bietet Dienstleistung an
- nimmt Anfragen (Request) entgegen und liefert Daten (Response)
- Dienste sind z. B. HTTP, FTP, Mail
- Client: nimmt Dienstleistung in Anspruch
- initiiert eine Verbindung mit dem Server
- konsumiert Daten vom Server
- Pull: Client fragt Daten vom Server ab
- normale Form der Kommunikation im Internet
- hierfür ist HTTP gedacht
- Push: Server übermittelt von sich aus Daten an Client
- hat sich im Internet nur wenig durchgesetzt
- Broadcast Systeme, Channels, Abonnements
HTTP
HyperText Transfer Protocol (HTTP)
- einfaches Protokoll für die Übertragung von Hypertext-Dokumenten über das Internet
- Request / Response Verfahren über eine TCP-Verbindung
- mehrere Nachrichten über dieselbe Verbindung
- Verbindung kann auch nach jedem Request abgebaut werden
- Klartext-Protokoll
- reines ASCII
- unverschlüsselt
- zeilenorientiert
Beispiel: HTTP (Request)
GET / HTTP/1.1
Host: www.hs-mannheim.de
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cache-Control: max-age=0
Beispiel: HTTP (Response)
HTTP/1.1 200 OK
Date: Fri, 30 Sep 2022 21:10:50 GMT
Server: Apache/2.2.10 (Linux/SUSE)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Content-Encoding: gzip
Content-Length: 7010
Content-Type: text/html; charset=utf-8
<!DOCTYPE html> …
Interaktion bei HTTP
- Browser stellt Anfrage nach HTML-Seite
- Server liefert Seite
- Browser analysiert Seite und fordert alle abhängigen Ressourcen parallel vom Server an
Zustandslosigkeit
HTTP ist grundsätzlich zustandslos
- keine Zustand zwischen zwei Aufrufen eines Clients
- Verbindung kann zwischen Aufrufen abgebaut werden
- Browser-Sitzungen brauchen nicht geschlossen zu werden
Definition idempotent / sicher
Einen HTTP-Request, bei dem mehrfache (erfolgreiche) Zugriffe, die gleiche Wirkung haben wie ein einmaliger (erfolgreicher) Zugriff, nennt man idempotent.
Einen HTTP-Request, bei dem ein (erfolgreicher) Zugriffe keine unerwünschten Seiteneffekte auf dem Server erzeugt nennt man sicher.
Request-Line
Request-Line: erste Zeile des Requests
- HTTP-Methode der Anfrage (HTTP-Verb)
- URI der Ressource die angefordert wird
- HTTP-Version (immer noch oft HTTP/1.1)
GET / HTTP/1.1
Host: www.hs-mannheim.de
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cache-Control: max-age=0
Überblick: HTTP-Verben
| Verb | sicher | idempotent | URI zeigt auf Ressource | cachebar | Semantik definiert |
|---|---|---|---|---|---|
| GET | ✓ | ✓ | ✓ | ✓ | ✓ |
| HEAD | ✓ | ✓ | ✓ | ✓ | ✓ |
| PUT | ✓ | ✓ | ✓ | ||
| POST | |||||
| OPTIONS | ✓ | ✓ | ✓ | ||
| DELETE | ✓ | ✓ | ✓ |
GET, POST, HEAD und OPTIONS
- GET: Fordert eine Ressource an
- sollte keine Daten auf dem Server verändern (sicher)
- Formulardaten können in der URI übergeben werden
- POST: Sendet Daten zum Server
- darf Daten auf dem Server modifizieren (nicht sicher)
- Formulardaten werden im Body des Request übertragen
- HEAD: Fordert die Metadaten einer Ressource an
- wie GET, nur ohne Body
- wird vom Browser für das Caching verwendet
- OPTIONS: Liefert die Fähigkeiten des Servers
DELETE, PUT und PATCH
- DELETE: Löscht bestehende Ressource
- Für Web-Anwendungen nicht relevant (wichtig für REST)
- PUT: Aktualisiert eine Ressource oder legt sie neu an
- inverse Operation zu GET
- Für Web-Anwendungen nicht relevant (wichtig für REST)
- PATCH: Verändert Teile einer Ressource (ähnlich zu PUT)
- Erweiterung von HTTP/1.1 (RFC 5789) von 2010
- Nicht idempotent, nicht sicher
- Client sollte sich über ETag gegen mögliche Veränderungen der Ressource zwischen GET und PATCH schützen
Wichtige Unterschiede GET/ POST
GET übermittelt alle Formulardaten in der URL
- Variablen werden mit ? an die URL angehängt
- für jede Variable name=wert, durch & getrennt
- Vor- und Nachteile
- Parameter werden in Bookmarks gespeichert
- Parameter können auch manuell angehängt werden
- URLs werden sehr lang
- Viele Web-Server beschränken die URL-Länge (Apache 8190 Bytes)
- Parameter sind sofort in der URL sichtbar
- GET sollte keine Daten auf dem Server verändern
POST übermittelt Formulardaten im Request-Body
- kurze URLs
- Beliebig große Daten können übertragen werden
- Parameter nicht in Bookmarks speicherbar
- Parameter tauchen nicht in URL auf
- POST ist für Datenänderungen geeignet
Response-Line
Response-Line: erste Zeile des Responses
- HTTP-Version (heute immer HTTP/1.1)
- Status-Code
HTTP/1.1 200 OK
Date: Fri, 30 Sep 2022 21:10:50 GMT
Server: Apache/2.2.10 (Linux/SUSE)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Content-Encoding: gzip
Content-Length: 7010
Content-Type: text/html; charset=utf-8
HTTP-Status-Codes
| Code | Name | Beschreibung |
|---|---|---|
| 1xx | Informational | Response wurde ausgelöst, der Request ist aber noch nicht vollständig verarbeitet, z. B. 101 Protocol Switch |
| 2xx | Success | Keine Probleme aufgetreten und der Request konnte verarbeitet werden, z. B. 200 OK |
| 3xx | Redirect | Client muss weitere Schritte durchführen, damit der Request bearbeitet werden kann, z. B. 303 See Other |
| 4xx | Client Error | Ursache des Fehlers liegt im Verantwortungsbereich des Clients, z. B. 404 Not Found |
| 5xx | Server Error | Ursache des Fehlers liegt im Verantwortungsbereich des Servers, z. B. 500 Internal Server Error |
100: Information
| Code | Name | Erklärung |
|---|---|---|
| 100 | Continue | Anfrage noch in Bearbeitung |
| 101 | Switching Protocols | Server stimmt Protokollwechsel zu (z. B. auf HTTPS) |
200: Erfolg
| Code | Name | Erklärung |
|---|---|---|
| 200 | OK | Anfrage erfolgreich bearbeitet |
| 201 | Created | Angeforderte Ressource erzeugt, URL im Location-Header |
| 202 | Accepted | Akzeptiert, wird später ausgeführt |
| 203 | Non-Authorative | Anfrage bearbeitet, Ergebnis aber mglw. veraltet |
| 204 | No Content | Anfrage akzeptiert, keine Ergebnisdaten |
| 205 | Reset Content | Client soll Dokument neu aufbauen |
| 206 | Partial Content | Angeforderter Teil erfolgreich übertragen (Range-Request) |
300: Umleitung
| Code | Name | Erklärung |
|---|---|---|
| 300 | Multiple Choice | Client soll aus Ressourcen auswählen |
| 301 | Moved Permanently | Ressource ist dauerhaft umgezogen, Adresse im Location-Header |
| 302 | Found | Ressource temporär umgez., Adresse im Location-Header (GET) |
| 303 | See Other | Antwort unter Adresse, die im Location-Header steht (GET) |
| 304 | Not Modified | Antwort gegenüber voriger Anfrage unverändert |
| 305 | Use Proxy | Ressource nur über Proxy (Adresse in Location-Header) erreichbar |
| 306 | - | (reserviert) |
| 307 | Temporary Redirect | Ressource temporär umgez., Adresse im Location-Header |
400: Client-Fehler
| Code | Name | Erklärung |
|---|---|---|
| 400 | Bad Request | Ungültige Anfrage-Nachricht |
| 401 | Unauthorized | Authentifizierung notwendig |
| 402 | Payment Required | (reserviert) |
| 403 | Forbidden | Zugriff verboten, unabhängig von Authentifizierung |
| 404 | Not Found | Ressource nicht gefunden |
| 405 | Method Not Allowed | Falsche Zugriffsmethode (GET / POST) |
| 406 | Not Acceptable | Ressource nicht im gewünschten Format verfügbar |
| 407 | Proxy Authentication | Authentifizierung (Login / Password) am Proxy notwendig |
| 408 | Request Time-out | Server hat Anfrage nicht innerhalb Server-Timeout empfangen |
| Code | Name | Erklärung |
|---|---|---|
| 409 | Conflict | Anfrage unter falschen Voraussetzungen (PUT-Konflikt) |
| 410 | Gone | Ressource dauerhaft entfernt, steht nicht mehr bereit |
| 411 | Length Required | Anfrage muss mit Content-Length gestellt werden |
| 412 | Precondition Failed | Voraussetzung (z. B. If-Match) trifft nicht zu |
| 413 | Request Entity Too Large | Anfrage ist zu groß |
| 414 | Request-URI Too Long | URI der Anfrage zu lang |
| 415 | Unsupported Media Type | Medientyp wird vom Server nicht unterstützt |
| 416 | Request Range Not Satisfiable | Angeforderter Range nicht vorhanden |
| 417 | Expectation Failed | Server kann gefordertes Verhalten (Expect-Header) nicht zeigen |
| 418 | I'm a teapot | Server kocht keinen Kaffee |
500: Server-Fehler
| Code | Name | Erklärung |
|---|---|---|
| 500 | Internal Server Error | Unerwarteter Serverfehler |
| 501 | Not Implemented | Funktionalität vom Server nicht implementiert |
| 502 | Bad Gateway | Proxy-Server hat ungültige Antwort vom benutzen Server erhalten |
| 503 | Service Unavailable | Server steht nicht zur Verfügung |
| 504 | Gateway Timed Out | Proxy-Server hat seinerseits Timeout vom benutzen Server erhalten |
| 505 | HTTP Version Not Supported | HTTP-Version vom Server nicht unterstützt |
HTTP-Header
Header kommen in Request und Response vor
- dienen Austausch von Meta-Daten zwischen Client und Server
- Syntax:
name: wert\r\n
GET / HTTP/1.1
Host: www.hs-mannheim.de
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cache-Control: max-age=0
General Header
- Date: Zeitpunkt der Anforderung oder Antwort
- Content-Type: Typ der Daten
- Content-Length: Länge der Daten in Bytes
- Content-Encoding: Codierung der Daten (Komprimierung)
- Last-Modified: letzte Änderung der Daten
Wichtige Header
Im Request
- Host: Name des Hosts im Request
- If-Modified-Since: Fordert nur aktualisierte Version an
- Referer: von welchem Dokument wurde dieses verwiesen
- User-Agent: Informationen über den Browser
Im Response
- Server: Information über den Server
- WWW-Authenticate: verlangt eine Authentifizierung
Content Negotiation
Der Client teilt dem Server mit, welche Medientypen und Formate er empfangen möchte (content negotiation)
GET / HTTP/1.1
Host: www.hs-mannheim.de
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cache-Control: max-age=0
HTTP/1.1 200 OK
Date: Fri, 30 Sep 2022 21:10:50 GMT
Server: Apache/2.2.10 (Linux/SUSE)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Content-Encoding: gzip
Content-Length: 7010
Content-Type: text/html; charset=utf-8
MIME-Typ
Content Negotiation basiert auf MIME-Typ (MIME type)
- MIME = Multi Purpose Internet Mail Extensions
- Definiert den Typ einer Nachricht im Internet
- Besteht aus
- Medientyp (content type)
- Subtyp (subtype)
- Syntax:
Medientyp/Subtyp - Ursprünglich für in RFC1049 für E-Mail spezifiziert, aktuelle Spezifikation ist RFC2045
- Liste der MIME-Typen wird von der IANA verwaltet
Medientyp
| Medientyp | Bedeutung | Beispiel(e) |
|---|---|---|
| text | Textuelle Daten | text/plain, text/html, text/xml |
| audio | Audio | audio/ogg, audio/mp4, audio/mpeg |
| image | Bilder | image/jpeg, image/tiff, image/gif |
| video | Video | video/mpeg, video/ogg |
| application | Programmspezifische Daten | application/zip, application/pdf |
| message | Nachrichten | message/rfc822, message/partial |
| multipart | Mehrteilige Daten | multipart/signed |
| example | Typ für Beispiele | : |
| model | Strukturierte Daten | model/mesh |
MIME-Typ und Zeichensatz
Zeichensatz-Codierung kann an den MIME-Typ angehängt werden
- Format:
MIME-Typ; charset=<charset-name>
Beispiel:text/plain; charset=UTF-8 - Wichtige Codierungen (nicht case-sensitive)
- US-ASCII
- ISO-8859-1
- UTF-8
- UTF-16, UTF-16BE, UTF-16LE
- UCS-4
- Achtung: text unterstützt kein UTF-16, UCS-4 und UTF-32
MIME und XML
IANA hat für XML-Dokumente ursprünglich die MIME-Typen text/xml und application/xml vorgesehen
- XML ist eine Meta-Sprache, es kann ganz unterschiedlichen XML-Anwendungen geben
- Für Verwender ist nicht zu erkennen für welche XML-Anwendung das Dokument (die Ressource) gedacht ist
- Daher verwendet man heute einen applikationsspezifischen MIME-Typ und hängt
+xmlan - application/atom+xml
- application/vcard+xml
- …
Hersteller-spezifische MIME-Typen
MIME-Typen müssen bei der IANA registriert werden
- Für interne Anwendungen unnötiger Aufwand
- Hersteller-Namensraum (vendor namespace) für Subtypen
- Aufbau:
vnd.<Herstellername>.<Subtyp> - Beispiele
- application/vnd.epson.esf
- application/vnd.nokia.pcd+xml
- application/vnd.oasis.opendocument.spreadsheet