Webtechnologien Wintersemester 2024

HTTP

Hypertext Transfer Protocol

Quelle: Markus Spiske

Ihr geht auf htw-berlin.de. Was genau passiert? Euer Browser benutzt eine Sprache, HTTP, um mit dem Server zu reden. Aber das ist keine Programmiersprache, sondern ein Protokoll. Eine Menge an Regeln, wie man miteinander redet. Wie in der echten Welt gibt es dabei feste Abläufe, beispielsweise komme ich zur dir und sage: Hi, mein Name ist Max. Und dann antwortest du mit deinem Namen. Dann schütteln wir Hände und haben dieses eigenartige Protokoll durchgezogen.

Aufbau

HTTP

  • Grundlegendes Protokoll des World Wide Web
  • Nachrichten basiert
  • Anfrage-Antwort-Paar
  • ASCII-Byte-Streams
  • Zustandslos
  • 1989 von Roy Fielding, Tim Berners-Lee und anderen am CERN entwickelt
  • aktuelle Version sind 1.1 / 2 / 3
  • simple request and response mechanism: Eine Anfrage hin, eine Antwort zurück
  • beide folgen demselben Format
  • ASCII: Kann einfach geschrieben und gelesen werden (HTTP 2.0 nicht mehr ASCII, HTTP 3.0 nicht mehr über TCP)

Aufbau einer GET-Anfrage

  • Der Client baut über den Domain-Namen oder die IP des Hosts eine TCP-Verbindung zum ihm auf
  • Ist kein Port gegeben, wird Port 80 verwendet
  • Der Client stellt eine Anfrage nach einem Dokument (beendet durch CRLF)
  • Die Anfrage beginnt mit dem Wort GET, einem Leerzeichen, der reinen Adresse und dann der verwendeten HTTP-Version
  • CRLF = carriage return, line feed
  • Protokoll, Host und Port werden nur für die initiale Verbindung benötigt

Beispielhafte GET-Anfrage

GET /index.php HTTP/1.1
Host: www.htw-berlin.de
Connection: keep-alive
Accept: text/html, … ;q=0.9,image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) …
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,de;q=0.6
  • Beispiel: nc -l 8080 und mit Browser zugreifen
  • Erste Zeile ist die Request Line
  • 3 Teile:
    • die Aktion (auch HTTP-Methode)
    • die Ressource (auf die die Aktion angewendet wird)
    • die HTTP-Version (1.1)
  • Danach kommen n Header-Lines (teilen zusätzliche Informationen mit)
    • Host: Domain-Name des Servers
    • Connection: Welchen Typ von Verbindung der Client bevorzugt (keep-alive, close) (close heißt: 10 Bilder im HTML = 11 Anfragen)
    • Accept: Welche Dateitypen der Client verarbeiten kann (Internet Media Type / MIME-Type: Angabe des Medientyps + Angabe eines Subtyps)
    • User-Agent: Informationen über den Client
    • Accept-Encoding: Welche komprimierten Formate der Client unterstützt. Über Content Negotiation wird eine passend komprimierte Datei ausgeliefert. (sdch = Shared Dictionary Compression Over HTTP (von Google))
    • Accept-Language: Welche Sprachen der Client akzeptiert. Auswahl per Content Negotiation. (q = quality factor)
    • Referrer: Herkunftsseite
    • Cookie
    • If-Modified-Since: datum
  • Header endet mit einer Leerzeile
  • Danach käme optional noch ein Body; hier aber nicht

Beispiel-Antwort

HTTP/1.1 200 OK
Date: Mon, 06 Oct 2014 16:07:02 GMT
Server: Apache
X-Powered-By: PHP/5.3.15
Set-Cookie: fe_typo_user=7ffafacc72…; path=/; domain=.htw-berlin.de
Cache-Control: private
Vary: User-Agent,Accept-Encoding
Content-Encoding: gzip
Content-Length: 3253
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
  • Beispiel: echo -e "HTTP/1.1 200 OK\r\n" | nc -l 8080
  • Erste Zeile ist oder Status Line
  • Header
    • Date: Zeitpunkt des Absendens
    • Server: Serverkennung (so wie User-Agent für den Client)
    • Set-Cookie: Ein Cookie
    • X-Powered-By: nicht-standardisiert, gibt die benutzte Technologie an
    • Cache-Control: Sagt, wie lange unterwegs gecachet werden darf (in Sekunden, e.g. max-age=3600). private = nur auf dem Client (nicht Proxy oder so)
    • Vary: Sagt Proxies, was sie zukünftig machen sollen
    • Content-Encoding: Codierung des Inhalts
    • Content-Length: Länge des Body in Bytes
    • Keep-Alive: informiert Client über Regeln zum Umgang mit der Verbindung
    • Connection: kennen wir schon
    • Content-Type: Der MIME-Typ der angeforderten Datei (noch vor Charset im HTML)

HTTP-Methoden

GET Anfragen einer Ressource
POST Anlegen einer Ressource (oder ändern)
HEAD Nur Header, nicht Body senden.
PUT Ersetzt eine Ressource (oder legt sie an)
DELETE Löschen einer Ressource
TRACE Echo der Anfrage
OPTIONS Liste der unterstützten Methoden
CONNECT Stellt einen Tunnel zur Verfügung und leitet weiter
PATCH Verändert eine Ressource (teilweise)
  • Viele HTTP-Methoden, man verwendet aber gemeinhin nur zwei.
  • GET: Soll nur Daten abrufen und sonst keine Auswirkungen haben (Res. verändern o.ä.)
  • POST: Schickt (unbegrenzt) Daten an den Server (Key-Value, binary) Es können auch hier Daten an die URI angehängt werden
  • HEAD: Wie GET, aber ohne Body
  • PUT und DELETE selten implementiert, aber durch REST wieder populär (~ CRUD per HTTP)
  • TRACE: Sinnvoll für das Debugging von Verbindungen (e.g. ob Proxy was verändert hat)
  • OPTIONS: Quasi Speisekarte des Servers

HTTP-Methoden – Argumente

GET

  • Daten Teil der URL / des Headers
  • Bleiben in der History
  • Landen womöglich in Server-Logs

POST

  • Daten im Body
  • Werden (meist) nicht gespeichert
JA:   https://host.tld/search.php?q=Suchbegriff
NEIN: https://host.tld/login.php?name=admin&password=auchadmin
  • Sharing: GET liefert theoretisch selbes Ergebnis, POST wahrscheinlich nicht

HTTP-Methoden – Beispiel POST

POST /wiki/Spezial:Search HTTP/1.1
Host: de.wikipedia.org
Content-Type: application/x-www-form-urlencoded
Content-Length: 24

search=Katzen&go=Artikel


HTTP/1.1 302 Found
Date: Fri, 13 Jan 2006 15:32:43 GMT
Location: https://de.wikipedia.org/wiki/Katzen

Status Codes

Code Gruppe Bedeutung
1xx Informational Bearbeitung der Anfrage dauert noch an
2xx Success Anfrage war erfolgreich
3xx Redirection Bearbeitung erfordert weitere Schritte des Clients
4xx Client Error Ursache des Scheiterns liegt wohl bei Client
5xx Server Error Ursache des Scheiterns liegt wohl bei Server

Status Codes – häufig verwendet

Code Nachricht Bedeutung
200 OK Anfrage erfolgreich beendet
201 Created Alles gut, Ressource angelegt.
301 Moved Permanently Adresse nicht mehr gültig, Umleitung zu neuer Location
307 Temporary Redirect Vorübergehend woanders vorhanden
  • 201: Das Location-Header-Feld enthält eventuell die Adresse der erstellten Ressource.
  • 301: SEO: Suchmaschine zeigt zukünftig auf neue URL (gut bei Domainumzug, Redesign etc)

Status Codes – häufig verwendet

Code Nachricht Bedeutung
401 Unauthorized Authentifizierung erfordert
403 Forbidden Client ist nicht berechtigt
404 Not Found Ressource wurde nicht gefunden
500 Internal Server Error Irgendwas ging auf dem Server schief
503 Service Unavailable Server eventuell überlastet
  • 401: Im WWW-Authenticate-Header-Feld steht wie geauthet werden soll
  • 404: Kann auch benutzt werden, um ohne näheren Grund abzulehnen
  • 503: Server steht temporär nicht zur Verfügung, zum Beispiel wegen Überlastung oder Wartungsarbeiten. Ein Retry-After-Header-Feld in der Antwort kann den Client auf einen Zeitpunkt hinweisen, zu dem die Anfrage eventuell bearbeitet werden könnte.

Beispiel: cURL

curl -v htw-berlin.de

Anfrage

GET / HTTP/1.1
User-Agent: curl/7.30.0
Host: htw-berlin.de
Accept: */*

Antwort

HTTP/1.1 302 FOUND
Server: Apache
Location: http://www.htw-berlin.de/
Content-Length: 0
Content-Type: text/plain; charset=ISO-8859-1
  • cURL benutzt keinen Cache, darum sehen Anfragen immer gleich aus

Beispiel: cURL

Anfrage

GET / HTTP/1.1
User-Agent: curl/7.30.0
Host: www.htw-berlin.de
Accept: */*

Antwort

HTTP/1.1 200 OK
Server: Apache
X-Powered-By: PHP/5.3.15
Set-Cookie: fe_typo_user=7dc990a5a…
Cache-Control: private
Content-Type: text/html; charset=utf-8

<!DOCTYPE html>
<html lang="de">
<head>
…
  • Dokument wird ausgeliefert, obwohl nicht explizit angegeben → Config

Cookies

  • HTTP zustandslos → Erschwert Indentifizierung eines Nutzers
  • Entwicklung der Magic Cookies durch Netscape
  • Älteste und weitest verbreitete Speichermöglichkeit im Client
  • Werden bei jeder HTTP-Anfrage mitgeschickt
  • Unterscheidung zwischen Session cookie und Persistent cookie
Set-Cookie: value[; expires=date][; domain=name][; path=path]
   [; secure][; HttpOnly]
  • Overhead (Cookie-less-Domains)
  • Tracking durch externe Ressourcen
  • Können durch JavaScript geschrieben und gelesen werden
  • Session cookie: Wenn kein Verfallsdatum gesetzt, gelöscht mit Schließen des Browsers
  • Persistent cookie: Bleiben gesetzte Zeit X bestehen
  • Nutzung: SessionID, Cache-Botschafter

Cookies – 1. Anfrage

GET / HTTP/1.1
Host: www.facebook.com

Cookies – 1. Antwort

HTTP/1.1 200 OK
Set-Cookie: datr=cQw8VCSHQe2BlCBjtE4JvYOa;
   expires=Wed, 12-Oct-2016 17:31:55 GMT; Max-Age=63072000;
   path=/; domain=.facebook.com; httponly
Set-Cookie: reg_ext_ref=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT;
   Max-Age=0; path=/; domain=.facebook.com
Set-Cookie: reg_fb_ref=https%3A%2F%2Fwww.facebook.com%2F; path=/;
   domain=.facebook.com
Set-Cookie: reg_fb_gate=https%3A%2F%2Fwww.facebook.com%2F; path=/;
   domain=.facebook.com

Cookies – Folgende Anfragen

GET / HTTP/1.1
Cookie: datr=cQw8VCSHQe2BlCBjtE4JvYOa;
   reg_fb_ref=https%3A%2F%2Fwww.facebook.com%2F;
   reg_fb_gate=https%3A%2F%2Fwww.facebook.com%2F

HTTP-Authentifizierung

HTTP-Authentifizierung

  • Authentifizierung muss serverseitig konfiguriert werden
  • Verfahren
    • Basic Authentication
    • Digest Access Authentication
  • Konfig im Apache HTTP Server in .htaccess und .htpasswd-Datei
  • Basic Authentication:
    • Browser sucht nach Benutzername und Passwort
    • Fragt gegebenenfalls User und speichert Antwort
    • Schickt zukünftig jeder Anfrage die Base64-kodierte Version mit
    • Keine Verschlüsselung! (Kodierung = andere Darstellung von Klartext)
  • Digest Access Authentication
    • Server sendet Nonce
    • Client berechnet Hash (MD5, SHA1) aus Benutzername, Passwort, Nonce, HTTP-Methode und angeforderter URI
    • Sendet Benutzernamen, Hash und Nonce
    • sicher, solange Verfahren sicher, da Daten nicht rekonstruierbar
    • (MD5 nicht mehr sicher)

Beispiel: Basic Authentication

GET / HTTP/1.1

⇣

HTTP/1.1 401 Authorization Required
Server: Apache/2.2.16 (Debian)
WWW-Authenticate: Basic realm="Authorized personnel only."

⇣

GET / HTTP/1.1
Authorization: Basic YWRtaW46eW9sbw==

Debugging