原文地址：https://tus.io/protocols/resumable-upload.html
摘要
該協議提供一種基於 HTTP/1.1 和 HTTP/2 機制用於文件斷點續傳。
核心協議
核心協議描述如何繼續中斷的上傳。這里假定你已經有一個用於上傳的 RUL ，這個 URL 通常是由擴展協議 Creation創建。
所有客戶端和服務端必須實現核心協議。
協議沒有描述 RUL 的結構，而是留給協議的實現來決定。本文中所有展示的 URL 僅用於舉例。
此外，認證和授權的實現也留給服務端來決定。
示例
用一個請求頭指明應當從什么地方開始續傳上傳。
以下示例展示中斷位置由70變為100
請求
HEAD /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1
Host: tus.example.org
Tus-Resumable: 1.0.0
響應
HTTP/1.1 200 OK
Upload-Offset: 70
Tus-Resumable: 1.0.0
對於給定的中斷位置，客戶端使用 PATCH 方法來續傳。
請求
PATCH /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1
Host: tus.example.org
Content-Type: application/offset+octet-stream
Content-Length: 30
Upload-Offset: 70
Tus-Resumable: 1.0.0
[remaining 30 bytes]
響應
HTTP/1.1 204 No Content
Tus-Resumable: 1.0.0
Upload-Offset: 100
報文頭
Upload-Offset【上傳偏移位置】
請求和響應中的上傳便宜位置表明資源的字節偏移量。該值必須是一個非負整數。
Upload-Length【上傳長度】
請求和響應中的上傳長度表明資源的字節數【不是一次請求上傳的字節數】，該值必須是非負整數。
Tus-Version【協議版本】
響應頭中的協議版本值必須是由逗號分隔的服務器支持的協議列表，列表中的第一個必須是服務器最希望的版本。
Tus-Resumable
Tus-Resumable 頭除了 OPTIONS 請求外，每次請求和響應必須指明。Tus-Resumable
值必須是客戶端和服務器正在使用的協議版本。【更具體的說就是當前請求和響應使用的協議版本】
如果服務端不支持客戶端發過來的協議版本，服務端必須響應 412 Precondition Failed 狀態，並且響應頭中必須包括 Tus-Resumable，另外，服務端必須不處理這個請求。
Tus-Extension【擴展協議】
響應頭中的 Tus-Extension 值必須是有逗號分隔服務端支持的擴展協議的列表。如果服務端不支持擴展協議，則這個頭應當去掉。
Tus-Max-Size
協議頭中的 Tus-Max-Size 值必須是非負整數用以表明整個上傳最大允許的字節數【原文字面理解是上傳資源的最大限制字節數，不是一次請求的最大限制字節數】，服務端如果有硬性限制應當在這個頭中表明。
X-HTTP-Method-Override
如果這個請求頭有值，則服務端必須使用這個值當做請求方法【Method】，而當前請求的實際請求方法必須忽略。客戶端應當在其不支持 PATCH 或 DELETE 方法時使用該請求頭。【這個頭不是tus 創建的，http 原本就有，舉個例子：客戶端不能發生 PATCH 請求，於是發送一個 Get 請求，在 X-HTTP-Method-Override 頭中設置值為 PATCH ，這個服務端就知道客戶端想發的是 PATCH 請求】
請求
HEAD
服務端在接收到 HEAD 請求后，其必須總是在響應頭中包含 Upload-Offset 表明上傳偏移位置，即便偏移位置是 0，或上傳已經完成。如果知道上傳資源的長度，服務端必須在 Upload-Length 指明長度。如果服務端沒有找到上傳的資源，服務端應當返回 404 Not Found、410 Gone 或 403 Forbidden，且沒有 Upload-Offset 頭。
服務端必須在響應頭中包含 Cache-Control: no-store 來阻止客戶端或客戶端代理從緩存中獲取響應。
PATCH
服務端應當接受任何 PATCH 上傳請求，並且將請求體中的內容放在 Upload-Offse 頭指示的位置后。使用 PATCH 請求必須使用 Content-Type: application/offset+octet-stream 請求頭，否則服務端應當響應 415 Unsupported Media Type 狀態。
Upload-Offset 報文頭的值必須與資源的偏移量相等。出於並行上傳考慮，可以使用 Concatenation 擴展協議。如果上傳偏移量與資源實際偏移不相同，服務端應當返回 409 Conflict 狀態，且不修改資源。
如果 PATCH 請求沒有包含 Content-Length 頭，或者 Content-Length 值不是非負整數，服務端應當返回 400 Bad Request 狀態。
客戶端應當在一個 PATCH 請求中發送所有未發送的字節，但是可能存在發送多個較小的請求的場景。一個這樣的示例是使用了 Checksum 擴展協議。
服務端必須響應 204 No Content 狀態來表明成功處理 PATCH 請求。響應必須包含 Upload-Offset 報文頭，當然必須使用更新后的值。更新后的值必須是上一個請求偏移量和接收內容的和。
如果服務端接收到一個不存在資源的 PATCH 請求，應當返回 404 Not Found 狀態。
客戶端和服務器應當嘗試檢測和處理可預見的網絡錯誤，比如讀寫 socket 錯誤和讀寫超時，當連接超時應當關閉底層連接。
服務端應當總是嘗試存儲盡可能多接收數據。
OPTIONS
一個 OPTIONS 請求可能被用於收集服務端當前的配置，一個成功的響應應當返回 204 No Content 或 200 OK 狀態，並且必須包含 Tus-Version 響應頭，它可能包含 Tus-Extension 和 Tus-Max-Size 頭。
示例
請求
OPTIONS /files HTTP/1.1
Host: tus.example.org
響應
HTTP/1.1 204 No Content
Tus-Resumable: 1.0.0
Tus-Version: 1.0.0,0.2.2,0.2.1
Tus-Max-Size: 1073741824
Tus-Extension: creation,expiration
擴展協議
待補充