Range-Requests für fortsetzbare Downloads bedienen

Ziel

Clients ermöglichen, unterbrochene Übertragungen grosser Dateien fortzusetzen und Teile davon abzurufen, ohne alles herunterzuladen, auf eine Weise, die Zwischenstationen verstehen.

Voraussetzungen

Dateien, die als stabile Repräsentationen mit einem starken ETag und Last-Modified ausgeliefert werden, sowie kein On-the-fly-Content-Encoding: Byte-Bereiche beziehen sich auf die kodierte Repräsentation, sodass eine pro Anfrage komprimierte Antwort keine stabilen Offsets hat. Die Unterstützung von Bereichen ist optional, daher muss jeder Client auch mit einer vollständigen 200-Antwort zurechtkommen.

Schritte

1. Bei vollständigen Antworten für herunterladbare Ressourcen Accept-Ranges: bytes und ein starkes ETag senden; der Header lädt Clients dazu ein, Bereiche zu versuchen.
2. Range nur bei GET berücksichtigen, der einzigen Methode mit definierter Bereichsbehandlung. Unbekannte Bereichseinheiten ignorieren. RFC 9110 erlaubt, ungültige Angaben, überlappende Bereiche oder viele kleine, ungeordnete Bereiche als Schutz gegen Denial-of-Service zu ignorieren oder abzulehnen.
3. Zuerst Vorbedingungen prüfen: Ein bedingtes GET, das 304 ergibt, ignoriert Range. Danach If-Range prüfen: Ein Entity-Tag muss mit starkem Vergleich übereinstimmen (Clients DÜRFEN dort KEINE schwachen Tags senden), ein HTTP-Datum muss exakt Last-Modified entsprechen; erfüllt die Bedingung nicht, Range ignorieren und die vollständige 200-Antwort senden.
4. Bei einem erfüllbaren Bereich mit 206 Partial Content antworten, mit Content-Range: bytes 500-999/1234, einer Content-Length, die dem Teil entspricht, sowie denselben Werten für ETag, Content-Type, Last-Modified und Cache-Control wie bei der vollständigen Antwort.
5. Bei mehreren Bereichen einen multipart/byteranges-Body mit je einem Content-Range pro Teil aufbauen; RFC 9110 erlaubt es einem Server, überlappende oder nahezu benachbarte Bereiche zusammenzufassen und nur eine Teilmenge des Angeforderten zu senden.
6. Ist kein Bereich erfüllbar, zum Beispiel eine erste Position jenseits der Länge, mit 416 Range Not Satisfiable und Content-Range: bytes */1234 antworten. Ein Suffix-Bereich, der länger als die Datei ist (bytes=-500 bei 300 Bytes), ergibt die gesamte Repräsentation.
7. Clientseitig: das ETag aus der ersten Antwort behalten; zum Fortsetzen Range: bytes=<received>- mit If-Range: "<etag>" senden; bei 206 vor dem Anhängen prüfen, ob die erste Position in Content-Range dem lokalen Offset entspricht; bei 200 die unvollständige Datei verwerfen und neu beginnen.
8. Testen mit curl -r 0-99 -D - URL, einer Fortsetzung (curl -C - -O URL), einer Anfrage nach dem Ersetzen der Datei sowie mit bytes=0-0,-1 für Multipart.

Erwartetes Ergebnis

Unterbrochene Downloads setzen am Byte-Offset fort; eine zwischen Versuchen ersetzte Datei wird erneut von vorne abgerufen statt zusammengesetzt; Caches, die Bereiche implementieren, beantworten einen Teilbereich aus einer gespeicherten Kopie, was RFC 9111 sogar aus einer unvollständigen erlaubt, sofern der Bereich vollständig darin liegt.

Grenzen und Prüfbasis

Generierte oder ausgehandelte Inhalte brauchen eine stabile Repräsentation je Variante. Eine 206-Antwort kann aus dem Cache einer Zwischenstation stammen; RFC 9111 verbietet einem Cache, Teilantworten zu speichern, deren Bereichseinheit er nicht versteht. Die Schritte folgen den zitierten Spezifikationen; es werden keine Durchsatz- oder Fehlerratenzahlen behauptet.