Große Downloads fortsetzen: Die fehlenden Bytes müssen zur selben Datei gehören
Wenn Kunden große Dateien aus Ihrem Portal herunterladen, ist ein Verbindungsabbruch besonders ärgerlich. Eine Fortsetzung kann erneute Übertragung vermeiden. Versprechen Sie sie aber nur für einen geprüften Ablauf: Der bereits empfangene Teil und die nachgeladenen Daten müssen zur gleichen Dateifassung gehören.
Hier geht es um die Übertragung eines Downloads. Wer das Dokument erhalten darf, wann ein Zugriffslink endet und welche Käufer eine neue Ausgabe bekommen, sind davon getrennte Entscheidungen. Eine Übertragungstechnik ersetzt keine Berechtigungsprüfung.
Fortsetzen ist nicht einfach erneut auf Download klicken
Bei einem vollständigen Neustart fordert das Gerät die Datei erneut an. Bei einer Fortsetzung versucht es, nur den noch fehlenden Teil zu bekommen. Welche Variante die eingesetzte App oder der Browser tatsächlich unterstützt, muss im Projekt geprüft werden.
RFC 9110, Abschnitt 14, beschreibt HTTP-Bereichsanfragen. Eine Anfrage kann damit Teile der ausgewählten Repräsentation verlangen. Der Standard erlaubt einem Server allerdings auch, die Range-Angabe zu ignorieren. Eine vorhandene Dateiadresse allein verspricht daher noch keine Fortsetzung.
Fragen Sie, wer die Übertragung verwaltet: der gewöhnliche Browserdownload oder ein eigens entwickelter Downloadablauf in Ihrer App. Eine zusätzliche Schaltfläche „Fortsetzen“ auf der Webseite erzeugt nicht von selbst Zugriff auf einen bereits teilweise gespeicherten Browserdownload.
Ein Unterstützungsmerkmal ist noch kein Abnahmetest
Der Standard beschreibt Accept-Ranges als Hinweis auf unterstützte Bereichsanfragen. Er warnt ausdrücklich davor, daraus abzuleiten, dass eine spätere Anfrage tatsächlich wieder eine Teilantwort liefert. Der Inhalt, die Bedingungen oder ein beteiligter Vermittler können sich geändert haben.
Lassen Sie deshalb den realen Auslieferungsweg testen, einschließlich der verwendeten Speicher- und Zwischenschichten. Die passende Einstellung am Ursprung beweist nicht, dass der gesamte Kundenweg wie vereinbart funktioniert.
Eine normale Teilantwort kann den Status 206 tragen; eine nicht erfüllbare Bereichsanfrage kann zu 416 führen. Diese Angaben helfen der Entwicklung bei der Diagnose. Kunden brauchen dagegen eine verständliche Aussage darüber, ob die Datei fortgesetzt wird, neu beginnt oder nicht mehr abrufbar ist.
Eine geänderte Datei darf nicht an den alten Anfang angehängt werden
Ein fiktives Schulungsportal ersetzt ein großes Medienpaket, während ein Kunde noch einen Teil der vorherigen Fassung auf dem Gerät hat. Beide Pakete können denselben sichtbaren Namen besitzen. Das macht ihre Inhalte nicht austauschbar.
RFC 9110, Abschnitt 13.1.5, beschreibt dafür die Bedingung If-Range. Vereinfacht: Ist die Repräsentation unverändert, kann der angeforderte Teil übertragen werden. Passt die Prüfung nicht, wird die Bereichsanforderung ignoriert und die neue vollständige Repräsentation übertragen. Dabei gelten die im Standard beschriebenen Anforderungen an die verwendeten Validatoren.
Für Ihre Abnahme ist die fachliche Konsequenz wichtiger als der Headername: Ein vollständiger neuer Inhalt darf nicht unbemerkt an einen alten Dateianfang angehängt werden. Die Implementierung muss erkennen, welche Antwort sie erhalten hat, und den vereinbarten Neustart beziehungsweise Versionswechsel sauber behandeln.
Lassen Sie außerdem festlegen, ob ein Kunde eine begonnene ältere Ausgabe weiterhin erhalten soll oder ob nur die aktuelle Fassung angeboten wird. Das ist eine Produkt- und Zugriffsentscheidung, keine automatische Wirkung von If-Range.
Einen abgelaufenen Zugriff nicht durch Fortsetzung umgehen
Jede neue Anfrage muss den vorgesehenen Zugriffsweg einhalten. Ein gespeicherter Teil der Datei begründet kein neues Dokumentrecht. Wenn die Freigabe inzwischen abgelaufen ist, braucht die Oberfläche die vereinbarte erneute Berechtigungsprüfung oder eine verständliche Ablehnung.
Meine Empfehlung: Unterscheiden Sie „Verbindung unterbrochen“, „Dateifassung geändert“, „Zugriff abgelaufen“ und „Datei nicht mehr vorhanden“. Diese Situationen verlangen unterschiedliche nächste Schritte. Eine endlose automatische Wiederholung ist keine hilfreiche Fehlerbehandlung.
Geben Sie auch nicht vorschnell „Download abgeschlossen“ aus. Vereinbaren Sie, wie die Vollständigkeit des Ergebnisses im gewählten Downloadweg festgestellt wird. Ein erfolgreicher einzelner Teilabruf ist noch kein Nachweis einer vollständigen Datei.
Mit einer kontrollierten Testdatei abnehmen
Verwenden Sie eine unkritische Datei und nehmen Sie folgende Fälle in die Abnahmekriterien auf:
- Unterbrechung und Fortsetzung ohne Änderung der Datei.
- Eine ersetzte Datei zwischen den beiden Abrufen, mit sauberem vollständigem Neustart oder der vereinbarten Alternative.
- Eine Antwort mit vollständigem Inhalt statt des angeforderten Teils.
- Eine nicht erfüllbare Bereichsanfrage und eine inzwischen beendete Zugriffsfreigabe.
- Vergleich des fertig erhaltenen Testdokuments mit der erwarteten vollständigen Fassung, etwa durch eine vom Testwerkzeug berechnete Prüfsumme.
Führen Sie das im tatsächlichen unterstützten Browser oder in der App durch. Dokumentieren Sie ausdrücklich, wo nur ein Neustart angeboten wird. Ein ehrlicher vollständiger Download ist besser als eine scheinbare Fortsetzung mit beschädigtem Ergebnis.
Bringen Sie Dateigrößen, Aktualisierungspolitik und typische Kundenverbindungen zum Gespräch über Ihr Portal mit. Das Ergebnis sollte ein nachvollziehbarer Übertragungsablauf sein, nicht die pauschale Zusage, jeder Download lasse sich jederzeit weiterführen.
Quelle und Grenzen
Die gelesenen Abschnitte 13.1.5 und 14 von RFC 9110 belegen Bereichsanfragen, Unterstützungsgrenzen, Teilantworten und bedingte Fortsetzung. Nutzerführung, Zugriffsabgrenzung und Testfälle sind Anforderungen für Ihr Projekt. Es wurde für diesen Artikel kein Browserdownload implementiert oder praktisch unterbrochen.