Große Uploads trotz Verbindungsabbruch zuverlässig annehmen

Ein großer Upload ist keine Anfrage, die gelegentlich fehlschlägt. Er ist eine Übertragung, die unterbrochen werden wird. Entscheidend ist nur, ob eine Unterbrechung den Nutzer die verbleibenden Bytes oder sämtliche Bytes kostet. Alles Weitere im Design ergibt sich aus dieser Entscheidung.

Worauf es besonders ankommt

• Uploads, die über die angegebene Anzahl hinausgehen, werden ohne Meldung verworfen. Eine Abweichung um eins bei dieser Zahl führt daher ohne Fehlermeldung zum Verlust von Dateien.
• Dateien dürfen bis zu 200 GB groß sein, die Assembly läuft jedoch weiterhin acht Stunden nach ihrer Erstellung ab.

POST /assemblies HTTP/1.1
Host: api2.transloadit.com
Content-Type: multipart/form-data; boundary=---xyz

-----xyz
Content-Disposition: form-data; name="params"

{"auth":{"key":"YOUR_KEY"},
 "template_id":"YOUR_TEMPLATE_ID"}
-----xyz
Content-Disposition: form-data;
  name="num_expected_upload_files"

2
-----xyz--

HEAD /resumable/files/136058f2ef4d HTTP/1.1
Host: api2-freja.transloadit.com
Tus-Resumable: 1.0.0

HTTP/1.1 204 No Content
Upload-Offset: 3000
Upload-Length: 10000

PATCH /resumable/files/136058f2ef4d HTTP/1.1
Host: api2-freja.transloadit.com
Tus-Resumable: 1.0.0
Upload-Offset: 3000
Content-Length: 7000
Content-Type: application/offset+octet-stream

const uppy = new Uppy().use(Transloadit, {
  waitForEncoding: true,
  assemblyOptions: async () => {
    // Your back end signs with the Auth Secret
    const res = await fetch('/api/tl-signature')
    const { params, signature } = await res.json()
    return { params, signature }
  },
})

Wissenswerte technische Details

• Die Assembly wird durch einen Multipart-POST erstellt, der params und num_expected_upload_files, aber keine Dateiinhalte überträgt. Die Antwort enthält tus_url, expected_tus_uploads, started_tus_uploads und finished_tus_uploads.
• Eine Assembly bleibt im Zustand ASSEMBLY_UPLOADING, bis jeder deklarierte tus-Upload abgeschlossen ist, selbst wenn einige der bereits empfangenen Dateien verarbeitet wurden.
• Jeder tus-Upload beginnt mit einem POST an tus_url, der assembly_url, filename und fieldname als Metadaten überträgt. Der Server antwortet mit der Upload-URL im Location-Header.
• Das Fortsetzen beginnt mit einer HEAD-Anfrage an diese Upload-URL, die im Header Upload-Offset die Anzahl der empfangenen Bytes meldet. Anschließend sendet eine PATCH-Anfrage die verbleibenden Bytes exakt ab diesem Offset.
• Zusätzliche Metadaten, die mit einem Upload gesendet werden, werden unter file.user_meta als Assembly Variable verfügbar und gelten jeweils für eine Datei. Im Gegensatz dazu gilt fields gemeinsam für jede Datei derselben Assembly.
• Der Upload ist auf acht Stunden und die Verarbeitung auf weitere acht Stunden begrenzt. Insgesamt gilt ab der Erstellung eine Höchstgrenze von sechzehn Stunden. Danach gibt die Assembly ASSEMBLY_EXPIRED zurück.

Ein praxisnaher Ansatz

Wann Transloadit hilfreich ist

Verwenden Sie Uppy mit dem Transloadit-Plugin im Browser oder andernorts einen beliebigen tus-Client und lassen Sie /upload/handle die Dateien empfangen. Erstellen Sie zuerst die Assembly mit num_expected_upload_files und senden Sie dann jede Datei an die tus_url, die im Assembly Status zurückgegeben wird.

Architekturgrenze

Mit der Wiederaufnahme lässt sich eine unterbrochene Übertragung fortsetzen, eine vergessene jedoch nicht. Uploads müssen innerhalb von acht Stunden nach Erstellung der Assembly abgeschlossen sein und die Verarbeitung innerhalb weiterer acht Stunden; insgesamt gilt eine Obergrenze von sechzehn Stunden ab der Erstellung. Danach gibt die Assembly ASSEMBLY_EXPIRED zurück, und die bereits empfangenen Bytes können nicht mehr verwendet werden.