RFC 7233 - HTTP/1.1: Bereichsanforderungen (Range Requests)
- Status: Proposed Standard
- Veröffentlicht: June 2014
- Stream: IETF
- Ersetzt: RFC2616
- Ersetzt durch: RFC9110
- Errata: Keine Errata
Dokumentinformationen
- RFC-Nummer: 7233
- Titel: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
- Titel (Deutsch): Hypertext Transfer Protocol (HTTP/1.1): Bereichsanforderungen
- Veröffentlichungsdatum: Juni 2014
- Autoren: R. Fielding (Adobe), Y. Lafon (W3C), J. Reschke (greenbytes)
- Ersetzt Dokument: RFC 2616
- Status: Standards Track (Standardpfad)
Zusammenfassung
Bereichsanforderungen ermöglichen es HTTP-Clients, einen oder mehrere Teilbereiche einer Ressource anzufordern, anstatt die gesamte Darstellung. Dies ist entscheidend für Fortsetzung unterbrochener Downloads, Multi-Thread-Downloads und Medien-Streaming.
Kernkonzepte
Was sind Bereichsanforderungen?
Bereichsanforderungen ermöglichen es dem Client zu sagen: "Ich benötige nur einen Teil dieser Ressource".
Vollständige Ressource: [================100MB================]
↓
Bereichsanforderung: [====10MB====]
Hauptanwendungsfälle
- Fortsetzung unterbrochener Downloads: Nach Unterbrechung fortsetzen
- Segmentierter Download: Parallel-Downloads mit mehreren Threads
- Video-Scrubbing: Zu bestimmter Videoposition springen
- PDF-Vorschau: Nur erste Seiten herunterladen
- Optimierung großer Dateien: Inhalte bei Bedarf laden
Range-Header-Feld
Grundlegende Syntax
Range: bytes=<start>-<end>
Beispiele
Einzelner Bereich:
GET /video.mp4 HTTP/1.1
Host: example.com
Range: bytes=0-1023
Fordert die ersten 1024 Bytes an.
Mehrere Bereiche:
GET /document.pdf HTTP/1.1
Host: example.com
Range: bytes=0-499, 1000-1499, 5000-5999
Fordert drei nicht zusammenhängende Bereiche an.
Offene Bereiche:
Range: bytes=1000- # Von 1000 bis Ende
Range: bytes=-500 # Letzte 500 Bytes
Range: bytes=0- # Von Anfang bis Ende (entspricht vollständiger Anforderung)
Accept-Ranges-Header
Der Server verwendet diesen Header, um anzuzeigen, ob Bereichsanforderungen unterstützt werden.
Bereichsanforderungen werden unterstützt:
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 10485760
Bereichsanforderungen werden nicht unterstützt:
HTTP/1.1 200 OK
Accept-Ranges: none
Content-Length: 10485760
206 Partial Content-Antwort
Erfolgreiche Bereichsanforderungen geben den Statuscode 206 zurück.
Einzelbereichsantwort
GET /video.mp4 HTTP/1.1
Range: bytes=1000-1999
HTTP/1.1 206 Partial Content
Content-Range: bytes 1000-1999/10485760
Content-Length: 1000
Content-Type: video/mp4
[1000 Bytes Daten...]
Content-Range-Header
Format:
Content-Range: bytes <start>-<end>/<total>
Beispiel:
Content-Range: bytes 1000-1999/10485760
^^^^^ ^^^^^ ^^^^^^^^
Start Ende Gesamtgröße
Mehrbereichsantwort
Verwendet den Medientyp multipart/byteranges:
GET /file.txt HTTP/1.1
Range: bytes=0-50, 100-150
HTTP/1.1 206 Partial Content
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES
Content-Type: text/plain
Content-Range: bytes 0-50/1270
[Erste 51 Bytes...]
--THIS_STRING_SEPARATES
Content-Type: text/plain
Content-Range: bytes 100-150/1270
[Mittlere 51 Bytes...]
--THIS_STRING_SEPARATES--
416 Range Not Satisfiable
Wird zurückgegeben, wenn der angeforderte Bereich ungültig ist.
GET /file.txt HTTP/1.1
Range: bytes=9999-10999
HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */1234
Content-Length: 0
Häufige Ursachen:
- Startposition überschreitet Dateigröße
- Startposition größer als Endposition
- Formatfehler
If-Range bedingte Bereichsanforderung
Kombiniert bedingte Anforderungen und Bereichsanforderungen, um sicherzustellen, dass die Ressource nicht geändert wurde.
GET /video.mp4 HTTP/1.1
Range: bytes=1000000-
If-Range: "etag-abc123"
Ressource unverändert (ETag stimmt überein):
HTTP/1.1 206 Partial Content
ETag: "etag-abc123"
Content-Range: bytes 1000000-10485759/10485760
Ressource geändert (ETag stimmt nicht überein):
HTTP/1.1 200 OK
ETag: "etag-xyz789"
Content-Length: 10485760
[Vollständige neue Ressource zurückgeben...]
Praktische Anwendungsszenarien
Szenario 1: Fortsetzung unterbrochener Downloads
Erster Download (unterbrochen):
→ GET /large-file.zip HTTP/1.1
← HTTP/1.1 200 OK
Content-Length: 104857600
ETag: "file-v1"
[Unterbrochen bei 50MB...]
Fortsetzung des Downloads:
→ GET /large-file.zip HTTP/1.1
Range: bytes=52428800-
If-Range: "file-v1"
← HTTP/1.1 206 Partial Content
Content-Range: bytes 52428800-104857599/104857600
[Verbleibende 50MB herunterladen...]
Szenario 2: Video-Streaming-Wiedergabe
Benutzer klickt auf Fortschrittsbalken (springt zu 50%):
→ GET /movie.mp4 HTTP/1.1
Range: bytes=524288000-524877999
← HTTP/1.1 206 Partial Content
Content-Range: bytes 524288000-524877999/1048576000
Content-Type: video/mp4
[590KB Videodaten zurückgeben...]
Szenario 3: Multi-Thread-Download
Thread 1:
→ Range: bytes=0-34999999
Thread 2:
→ Range: bytes=35000000-69999999
Thread 3:
→ Range: bytes=70000000-104857599
[Drei Threads laden parallel herunter, dann zusammenführen]
Szenario 4: Teilweises Laden von PDFs
Nur Inhaltsverzeichnis und erste 10 Seiten des PDFs laden:
→ GET /document.pdf HTTP/1.1
Range: bytes=0-102400
← HTTP/1.1 206 Partial Content
Content-Range: bytes 0-102400/10485760
[Dateikopf und erste 10 Seiten zurückgeben...]
Content-Range-Antwort-Header
Vollständige Syntax
Content-Range: <unit> <range-start>-<range-end>/<size>
Content-Range: <unit> <range-start>-<range-end>/*
Content-Range: <unit> */<size>
Beispiele
Bekannte Gesamtgröße:
Content-Range: bytes 200-1000/5000
Unbekannte Gesamtgröße:
Content-Range: bytes 200-1000/*
Nicht erfüllbar (416-Antwort):
Content-Range: bytes */5000
Best Practices für Bereichsanforderungen
Serverseitig
-
Unterstützung deklarieren:
Accept-Ranges: bytes -
ETag oder Last-Modified bereitstellen:
ETag: "abc123"
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT -
Bereiche korrekt validieren:
- Prüfen, ob der Bereich im gültigen Bereich liegt
- Ungültige Bereiche ablehnen (416 zurückgeben)
-
Große Bereichsanforderungen optimieren:
- Erwägen, die Anzahl der Bereiche pro Anforderung zu begrenzen
- Zu kleine Bereiche vermeiden, die zu großem Overhead führen
Clientseitig
-
Accept-Ranges prüfen:
if (response.headers.get('Accept-Ranges') === 'bytes') {
// Bereichsanforderungen werden unterstützt
} -
If-Range verwenden, um Konsistenz sicherzustellen:
Range: bytes=1000-
If-Range: "etag-value" -
Verschiedene Antworten behandeln:
- 200: Server ignoriert Range, gibt vollständige Ressource zurück
- 206: Erfolgreiche Teilantwort
- 416: Bereich ungültig, möglicherweise erneut anfordern
-
Sinnvolle Segmentierung:
Nicht zu klein: bytes=0-1, bytes=1-2, bytes=2-3 ✗
Angemessene Größe: bytes=0-1048575 (1MB) ✓
Bereichseinheiten
HTTP/1.1 unterstützt hauptsächlich die Einheit bytes, die Spezifikation erlaubt jedoch Erweiterungen:
Accept-Ranges: bytes, frames, segments
Die bytes-Einheit ist die am häufigsten verwendete und standardisierte.
Leistungsüberlegungen
Vorteile
- Bandbreite sparen: Nur den benötigten Teil übertragen
- Erfahrung verbessern: Fortsetzung unterbrochener Downloads und schnelles Springen unterstützen
- Paralleler Download: Download-Geschwindigkeit erhöhen
Potenzielle Probleme
- Caching-Komplexität: Caching von Teilantworten ist komplexer
- Server-Overhead: Unterstützung für zufälligen Zugriff erforderlich
- Bereichsfragmentierung: Zu viele kleine Bereichsanforderungen können die Effizienz verringern
Optimierungsempfehlungen
Empfohlene Bereichsgrößen:
- Video-Streaming: 1-5MB
- Datei-Downloads: 5-10MB
- Dokumentbrowsing: 100KB-1MB
Sicherheitsüberlegungen
Denial-of-Service-Angriffe
Böswillige Clients könnten zahlreiche kleine Bereichsanforderungen senden:
Range: bytes=0-0, 1-1, 2-2, 3-3, ... (Tausende von Bereichen)
Abwehrmaßnahmen:
- Anzahl der Bereiche pro Anforderung begrenzen (z.B. maximal 5)
- Gesamtgröße der Antwort begrenzen
- Rate Limiting implementieren
Informationsleckage
Bereichsanforderungen könnten verwendet werden, um Dateigröße oder -struktur zu erraten:
Range: bytes=0-0
→ Content-Range: bytes 0-0/[Dateigröße]
Für sensible Dateien sollten Sie erwägen, Bereichsanforderungen zu deaktivieren oder Authentifizierung zu erfordern.
Interaktion mit anderen HTTP-Funktionen
Interaktion mit Caching
Bereichsanforderungen erhöhen die Komplexität des Cachings:
Vary: Range
Cache-Control: private
Interaktion mit Kompression
Hinweis: Bereichsanforderungen werden normalerweise nicht zusammen mit Content-Encoding: gzip verwendet, da komprimierte Offsets nicht vorhersehbar sind.
Empfehlung: Für große Dateien, die Bereichsanforderungen erfordern, keine Übertragungskompression verwenden.
Interaktion mit Umleitungen
Wenn eine Bereichsanforderung auf eine Umleitung trifft:
GET /old-video.mp4 HTTP/1.1
Range: bytes=1000-1999
HTTP/1.1 302 Found
Location: /new-video.mp4
Der Client sollte die Bereichsanforderung an der neuen URL erneut senden.
Zusammenfassung
Bereichsanforderungen sind ein Schlüsselmerkmal von HTTP/1.1:
- Genauigkeit: Präzise Implementierung der Byte-Bereichssemantik
- Klarheit: Klare Ausdrucksmöglichkeit für Teilinhaltsanforderungen
- Eleganz: Elegante Unterstützung fortgeschrittener Funktionen moderner Webanwendungen
Durch Bereichsanforderungen kann die Benutzererfahrung bei der Übertragung großer Dateien und beim Abspielen von Medien erheblich verbessert werden.
Verwandte RFCs:
- RFC 7230: HTTP/1.1 Nachrichtensyntax und Routing
- RFC 7231: HTTP/1.1 Semantik und Inhalt
- RFC 7232: HTTP/1.1 Bedingte Anforderungen