核心协议
核心协议描述了如何规复中断的上传。假定您已经有一个上载URL，常日是通过 Creation扩展创建的。
所有的客户端和做事器必须实现核心协议。
该规范未描述URL的构造，由于这留给特定的实现办法来决定。本文档中显示的所有URL仅用于示例目的。
其余，身份验证和授权的实现留给做事器决定。
例甲HEAD要求用于确定在上载应持续的偏移量。
下面的示例显示了100字节上传的连续，该上传在传输70字节后中断。
要求：
HEAD /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1Host: tus.example.orgTus-Resumable: 1.0.0
相应：
HTTP/1.1 200 OKUpload-Offset: 70Tus-Resumable: 1.0.0
给定偏移量后，客户端将利用该PATCH方法规复上传：
要求：
PATCH /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1Host: tus.example.orgContent-Type: application/offset+octet-streamContent-Length: 30Upload-Offset: 70Tus-Resumable: 1.0.0[remaining 30 bytes]
相应：
HTTP/1.1 204 No ContentTus-Resumable: 1.0.0Upload-Offset: 100header信息上传偏移
的Upload-Offset要乞降相应首部指示一个字节的资源内的偏移。该值必须是非负整数。
上传长度的Upload-Length要乞降相应首部以字节指示全体上载的大小。该值必须是非负整数。
Tus版本的Tus-Version相应报头必须是逗号分隔的由做事器支持的协议版本的列表。该列表必须按做事器的首选项进行排序，个中第一个是首选列表。
Tus可规复的Tus-Resumable报头必须被包含在每个要求中和除了相应OPTIONS要求。该值必须是客户端或做事器利用的协议版本。
如果做事器不支持客户端指定的版本，则它必须以412 Precondition Failed状态进行相应，并且必须Tus-Version在相应中包含 标头。其余，做事器不得处理该要求。
Tus扩展的Tus-Extension相应报头必须是逗号分隔的由所述做事器所支持的扩展名列表。如果不支持扩展，则Tus-Extension 必须省略头。
Tus最大限定的Tus-Max-Size相应报头必须是一个非负整数，其表示以字节为单位的全体上载所许可的最大尺寸。如果存在已知的硬限定，则做事器应设置此标头。
X-HTTP-方法重写如果X-HTTP-Method-Override要求头涌现，则要求头必须为字符串，做事器必须将其阐明为要求的方法。要求的实际方法必须被忽略。如果客户真个环境不支持PATCH或DELETE方法，则该当利用该头。
哀求
HEAD做事器必须始终Upload-Offset在HEAD要求的相应中包含标头 ，纵然偏移量为0，或者上传已被视为已完成。如果知道上传的大小，则做事器必须Upload-Length在相应中包含 标头。如果未找到资源，做事器将返回要么404 Not Found，410 Gone或403 Forbidden状态没有Upload-Offset头。
做事器必须通过将Cache-Control: no-store标头添加到相应中来防止客户端和/或代理缓存相应。
PATCH做事器该当接管PATCH针对任何上传URL的要求，并以Upload-Offset报头指定的给定偏移量运用中包含的字节 。所有PATCH要求都必须利用 Content-Type: application/offset+octet-stream，否则做事器该当返回一个415 Unsupported Media Type状态。
该Upload-Offset头的值必须即是当前资源的偏移。为了实现并行上传， 可以利用Concatenation扩展。如果偏移量不匹配，则做事器必须在409 Conflict不修正上传资源的情形下以状态相应。
客户端应在单个PATCH 要求中发送上载的所有剩余字节，但在须要时，也可以连续利用多个小要求。这些情形的一个示例 是利用Checksum扩展名。
做事器必须PATCH以204 No Content状态确认成功的要求 。它必须包括Upload-Offset包含新偏移量的头。新的偏移量必须是PATCH 要求之前的偏移量与当前PATCH要求期间吸收和处理或存储的字节数之和。
如果做事器收到PATCH针对不存在资源的要求，则应返回404 Not Found状态。
客户端和做事器均应考试测验可预测地检测和处理网络缺点。他们可以通过检讨读/写套接字缺点以及设置读/写超时来做到这一点。超时该当通过关闭根本连接来处理。
做事器应始终考试测验存储尽可能多的吸收数据。
OPTIONS一个OPTIONS要求可以用来网络有关做事器当前配置的信息。由204 No Content或200 OK状态指示的成功相应必须包含Tus-Version标题。它可以包含Tus-Extension和 Tus-Max-Size标头。
客户端不应该Tus-Resumable在要求中包含头，做事器必须忽略头。
例本示例阐明了OPTIONS要求的相应。相应中利用的版本是1.0.0Server还可以处理0.2.2和的版本0.2.1。许可上传的文件总大小最大为1GB，并且启用了创建和 过期扩展名。
要求：
OPTIONS /files HTTP/1.1Host: tus.example.org
相应：
HTTP/1.1 204 No ContentTus-Resumable: 1.0.0Tus-Version: 1.0.0,0.2.2,0.2.1Tus-Max-Size: 1073741824Tus-Extension: creation,expiration
协议扩展
鼓励客户端和做事器履行尽可能多的扩展。功能检测该当通过客户端发送 OPTIONS要乞降做事器相应Tus-Extension头来实现。
创建客户端和做事器该当实现上传创建扩展。如果做事器支持此扩展名，则必须添加creation到Tus-Extension 标题中。
例空POST要求用于创建新的上传资源。的 Upload-Length报头指示以字节为单位的全体上载的大小。
要求：
POST /files HTTP/1.1Host: tus.example.orgContent-Length: 0Upload-Length: 100Tus-Resumable: 1.0.0Upload-Metadata: filename d29ybGRfZG9taW5hdGlvbl9wbGFuLnBkZg==,is_confidential
相应：
HTTP/1.1 201 CreatedLocation: https://tus.example.org/files/24e533e02ec3bc40c387f1a0e460e216Tus-Resumable: 1.0.0
新资源具有隐式偏移量，0该偏移量许可客户端利用核心协议实行实际的上载。
header上传延迟韶光的Upload-Defer-Length要乞降相应标头指示上载的大小不是目前已知的，并且将在稍后传送。其值必须为1。如果上传的长度没有延迟，则必须省略此标头。
上传元数据的Upload-Metadata要乞降相应首部必须由一个或多个以逗号分隔的键-值对。键和值必须用空格分隔。键不得包含空格和逗号，且不得为空。密钥该当是ASCII编码的，值必须是Base64编码的。所有密钥必须唯一。该值可以为空。在这些情形下，常日会把键和值分开的空格可能会被忽略。
由于元数据可以包含任意二进制值，因此做事器在将它们用作头值之前应仔细验证元数据值或清理它们，以避免头走私。
哀求POST客户端必须POST针对已知的上传创建URL发送要求，以要求新的上传资源。该要求必须包含以下标头之一：
a）Upload-Length以字节为单位指示全体上传的大小。
b）Upload-Defer-Length: 1如果当时未知上传大小。一旦知道了，客户端必须Upload-Length不才一个PATCH要求中设置头。设置后，长度不得变动。只要上传的长度未知，做事器必须Upload-Defer-Length: 1在对HEAD要求的所有相应中 设置。如果Upload-Defer-Length标头包含任何其他值，1则做事器应返回一个400 Bad Request状态。
如果做事器支持延迟长度，则必须添加creation-defer-length到Tus-Extension报头中。
客户端可以供应Upload-Metadata标题，以将其他元数据添加到上传创建要求中。做事器可以决定忽略或利用该信息来进一步处理该要求或谢绝它。如果上载包含其他元数据，则对HEAD要求的相应必须包括Upload-Metadata标头及其在客户端在创建过程中指定的值。
如果上传的长度超过最大长度（可以利用Tus-Max-Size标题指定），则做事器务必以413 Request Entity Too Large状态相应 。
做事器必须以201 Created 状态确认成功的上传创建。做事器必须将Location头设置为创建资源的URL。该URL可以是绝对的或相对的。
客户端必须利用核心协议实行实际的上传。
上传创建客户端可以利用带有上载的创建扩展，在初初创立要求中包括上载的一部分。
如果做事器支持此扩展，则它必须通过creation-with-upload在Tus-Extension标头中包括来进行宣扬 。此外，此扩展直接取决于Creation扩展。因此，如果做事器不供应创建扩展名，则它也绝不能供应创建上载扩展名。
客户端可以在POST要求的主体中包含全部或部分上传数据。在这种情形下，适用与PATCH要乞降相应相似的规则。客户端必须包括 Content-Type: application/offset+octet-stream标题。做事器该当接管尽可能多的字节，并且必须Upload-Offset在相应中包含头，并且必须在运用接管的字节后将其值设置为上载的偏移量。
如果客户端要利用此扩展名，则客户端应在发送POST要求之前验证做事器是否支持该扩展名。其余，客户端应Expect: 100-continue在要求中包含标头，以便在考试测验传输第一个块之前，先从做事器吸收有关做事器是否接管创建要求的早期反馈。
例非空POST要求用于创建新的上传资源。Upload-Offset相应中的 标头指示已接管多少数据。
要求：
POST /files HTTP/1.1Host: tus.example.orgContent-Length: 5Upload-Length: 100Tus-Resumable: 1.0.0Content-Type: application/offset+octet-streamhello
相应：
HTTP/1.1 201 CreatedLocation: https://tus.example.org/files/24e533e02ec3bc40c387f1a0e460e216Tus-Resumable: 1.0.0Upload-Offset: 5过期
一旦过期，做事器可以删除未完成的上传。为了向客户端指示此行为，做事器必须添加expiration到 Tus-Extension报头。
例未完成的上载直到中指定的韶光才可用Upload-Expires。在此日期之后，无法规复上传。
要求：
PATCH /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1Host: tus.example.orgContent-Type: application/offset+octet-streamContent-Length: 30Upload-Offset: 70Tus-Resumable: 1.0.0[remaining 30 bytes]
相应：
HTTP/1.1 204 No ContentUpload-Expires: Wed, 25 Jun 2014 16:00:00 GMTTus-Resumable: 1.0.0Upload-Offset: 100header上传到期
的Upload-Expires相应报头指示之后将未完成上传期满的时候。做事器可能希望在给定的韶光段后删除不完全的上载，以防止废弃的上载占用额外的存储空间。客户端应利用此标头来确定上传是否仍旧有效，然后再考试测验连续上传。
PATCH如果上传即将过期，则此标头必须包含在每个相应中。如果在创建时已知道到期韶光，则Upload-Expires 必须在对初始POST要求的相应中包含头。它的值可能会随韶光变革。
如果客户端确实考试测验规复已被做事器删除的上载，则做事器应以404 Not Found或410 Gone状态相应。如果做事器跟踪过期的上传，则应利用后一种。在这两种情形下，客户端都应开始新的上传。
Upload-Expires标头的值必须为 RFC 7231日期韶光格式。
校验客户端和做事器可以实现并利用这个扩展来验证每个PATCH要求的数据完全性。如果支持，则做事器必须添加checksum 到Tus-Extension标题中。
客户可以Upload-Checksum在PATCH要求中包含头。一旦收到全体要求，做事器必须利用指定的算法根据供应的校验和来验证上传的块。根据结果，做事器可以利用以下状态代码之一进行相应：1）400 Bad Request如果做事器不支持校验和算法，2）460 Checksum Mismatch如果校验和不匹配，或者3）204 No Content如果校验和匹配并且数据处理成功。在前两种情形下，必须丢弃上传的块，并且不得更新上传及其偏移量。
做事器必须至少支持由标识的SHA1校验和算法sha1。校验和算法的名称必须仅由ASCII字符组成，但修正为不包括大写字符。
的Tus-Checksum-Algorithm报头必须被包含在相应于一个 OPTIONS要求。
如果不能在上传开始时打算出哈希值，则可以将其作为预报片包含在内。如果做事器可以处理预报片，则必须通过将其添加checksum-trailer到Tus-Extension标头中来宣告此行为。尾部，也称为尾部标头，是在要求主体已经被发送之后发送的标头。遵照 RFC 7230，必须利用Trailer标头宣告它们，并且仅许可在分块传输中利用。
headerTus-Checksum-算法的Tus-Checksum-Algorithm相应报头必须是一个逗号分隔的由做事器支持的校验和算法列表。
上传校验的Upload-Checksum要求报头包含关于当前体有效载荷的校验和信息。头必须由所用校验和算法的名称和以空格分隔的Base64编码校验和组成。
例哀求：
OPTIONS /files HTTP/1.1Host: tus.example.org
回应：
HTTP/1.1 204 No ContentTus-Resumable: 1.0.0Tus-Version: 1.0.0Tus-Extension: checksumTus-Checksum-Algorithm: md5,sha1,crc32
哀求：
PATCH /files/17f44dbe1c4bace0e18ab850cf2b3a83 HTTP/1.1Content-Length: 11Upload-Offset: 0Tus-Resumable: 1.0.0Upload-Checksum: sha1 Kq5sNclPz7QV2+lfQIuc6R7oRu0=hello world
回应：
HTTP/1.1 204 No ContentTus-Resumable: 1.0.0Upload-Offset: 11客户端终止
该扩展定义了客户端终止已完成和未完成的上传的办法，从而许可做事器开释已利用的资源。
如果做事器支持此扩展，则必须通过添加termination到Tus-Extension标头中来宣告 。
哀求DELETE当做事器收到一个DELETE现有的上传要求时，该当开释干系资源，并且必须以204 No Content确认上传已终止的状态进行相应。对付往后对该URL的所有要求，做事器应以404 Not Found或410 Gone状态相应。
例要求：
DELETE /files/24e533e02ec3bc40c387f1a0e460e216 HTTP/1.1Host: tus.example.orgContent-Length: 0Tus-Resumable: 1.0.0
相应：
HTTP/1.1 204 No ContentTus-Resumable: 1.0.0续传
此扩展名可用于将多个上传连接为一个上传，从而使客户端可以实行并行上载和上载不连续的块。如果做事器支持此扩展名，则必须添加concatenation到 Tus-Extension标题中。
部分上传代表文件的一部分。它是通过在Upload-Concat: partial利用“创建”扩展名创建新上传文件时包含标头来 布局的 。多个部分上载按指定顺序串联为终极上载。做事器不应处理这些部分上载，直到它们串联起来形成终极上载。终极上传的长度必须是所有部分上传的长度的总和。
为了创建新的终极上传，客户端务必将Upload-Concat标头添加到上传创建要求中。值后必须final紧跟一个分号和须要连接的部分上传URL的空格分隔列表。部分上传内容必须按照列表中指定的顺序进行串联。所有所有相应的部分上载完成后，都应发生此串联要求。客户端不得Upload-Length在终极的上载创建中包含标头。
当部分上传仍在进行时，客户端可以发送连接要求。做事器必须通过添加concatenation-unfinished到Tus-Extension标头中明确宣告此功能 。
创建新的终极上传文件时，部分上传文件的元数据不得转移到新的终极上传文件中。所有的元数据都应利用Upload-Metadata标头包含在连接要求中。
连接后，做事器可以删除部分上传。但是，它们可以多次利用以形成终极资源。
做事器必须以终极上传URL的403 Forbidden状态相应PATCH要求，并且绝不能修正终极或部分上传。
Upload-Offset 除非连接成功完成，对HEAD的终极上传要求的相应不应包含标头。成功连接后，将Upload-Offset和Upload-Length必须设置和它们的值必须相等。Upload-Offset没有为终极上传定义串联之前的标头值。
对HEAD哀求部分上传的相应必须包含Upload-Offset标头。
在Upload-Length必须被包含标头如果终极资源的长度可以在该要求的韶光来打算。HEAD针对部分上传或终极上传的要求的相应必须包括Upload-Concat标头及其在上传创建要求中收到的值。
header上传Concat的Upload-Concat要乞降相应首部必须在两个部分和终极的上载创建要求来设置。它指示上传是部分上传还是终极上传。如果上传是部分上传，则标头值务必为partial。在终极上传的情形下，其值必须final后跟一个分号和要连接的部分上传URL的空格分隔列表。部分上传URL可以是绝对URL或相对URL，并且不得包含RFC 3986中定义的空格。
例在以下示例中，为便于阅读，省略了Host和Tus-Resumable标头，只管规范哀求它们。在开始时，创建了两个部分上传：
POST /files HTTP/1.1Upload-Concat: partialUpload-Length: 5HTTP/1.1 201 CreatedLocation: https://tus.example.org/files/aPOST /files HTTP/1.1Upload-Concat: partialUpload-Length: 6HTTP/1.1 201 CreatedLocation: https://tus.example.org/files/b
现在，您可以利用PATCH 要求将数据上传到两个部分资源：
PATCH /files/a HTTP/1.1Upload-Offset: 0Content-Length: 5helloHTTP/1.1 204 No ContentPATCH /files/b HTTP/1.1Upload-Offset: 0Content-Length: 6 worldHTTP/1.1 204 No Content
在第一个要求中，该字符串hello已上传，而第二个文件现在包含带有前导空格的“ world”。
下一步是创建由两个较早天生的部分上传组成的终极上传。在以下要求中，未Upload-Length显示任何标头。
POST /files HTTP/1.1Upload-Concat: final;/files/a /files/bHTTP/1.1 201 CreatedLocation: https://tus.example.org/files/ab
现在，终极资源的长度为11个字节，由字符串组成 hello world。
HEAD /files/ab HTTP/1.1HTTP/1.1 200 OKUpload-Length: 11Upload-Concat: final;/files/a /files/b
常问问题
常见问题解答可从https://tus.io/faq.html在线得到。
## 实现:
golang: https://github.com/tus/tusd
php: https://github.com/ankitpokhrel/tus-php
原文: https://tus.io/protocols/resumable-upload.html
本文基于谷歌翻译
