HTTP部分上传、断点续传的标准方法

Question

我正在开发 http 客户端/服务器框架，并寻找处理部分上传的正确方法（与使用带有 Range 标头的 GET 方法下载相同）。

但是，HTTP PUT 并不打算恢复。 据我所知，PATCH 方法不接受 Range 标头。

有没有办法通过 HTTP 标准来处理这个问题（不使用扩展头等）？

Answer 1

我认为部分上传没有标准：

• RFC2616（http）中没有明确禁止请求中的内容范围，但措辞也将其称为响应标头，用于响应范围请求
虽然您可以使用 PATCH 方法来更新现有资源（例如添加更多字节），但它与部分上传不同，因为不完整的资源始终可用

如果你看看 Dropbox、Google Drive 等的协议，它们都会推出自己的协议来以多个块的形式传输单个文件。可恢复上传需要的是

解决上传不完整的方法。普通 URL 寻址的是完整的资源，而不是部分资源，据我所知，部分资源没有标准。
一种找出上传当前状态的方法，也许还可以确定本地文件没有更改的部分的校验和。这可以通过 WebDAV PROPFIND 方法提供（一旦您能够解决不完整的资源:)
一种上传块的方法。这里可以使用带有内容范围标头的 PATCH。 mod_dav 似乎允许使用内容范围标头进行 PUT（请参阅
• http://www.gossamer-threads.com/lists/apache/users/432346）
一种在资源完成后发布资源的方法，或者一种预先定义完整含义的方法（例如资源大小、校验和...）

Answer 2

PATCH 将是选择可续传上传的逻辑方法：它需要指示如何更改目标资源的媒体类型。虽然没有具体定义为执行修补的格式，但

multipart/byteranges

指定了字节范围以及该范围的内容，使其适合 PATCH 有效负载的良好定义。

示例：

PATCH /document HTTP/1.1
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: text/plain
Content-Range: bytes 10-21/22

1234567890
--THIS_STRING_SEPARATES--

此示例以 10 字节偏移量上传 12 字节。

THIS_STRING_SEPARATES

 是任意的、用户选择的分隔符，并且应该是随机生成的。为了简洁起见，省略了一些标题，每行以 ␍␊ 结尾。

Answer 3

正如一些评论中所指出的，新版本的 HTTP 规范已经在一定程度上澄清了这一点。根据 RFC 7231

第 4.3.4 节：

允许对给定目标资源进行 PUT 的源服务器必须发送 对包含以下内容的 PUT 请求的 400（错误请求）响应 Content-Range 标头字段（

[RFC7233]第 4.2 节），因为有效负载 可能是部分内容被错误地 PUT 为完整内容 表示。通过定位可以进行部分内容更新 单独标识的资源的状态与部分资源重叠 更大的资源，或者使用专门的不同方法 为部分更新定义（例如，在 [RFC5789]）。

不幸的是，

RFC 7233中出现的范围标头的讨论或多或少完全集中在 GET 请求上，而 RFC 5789 几乎没有定义任何有关 PATCH 的内容，除了明确不要求传输整个内容（但允许），也不要求是幂等的（但允许）。

好的一面是，由于 PATCH 的定义如此松散，它确实适应了相关问题的答案中给出的方法（

https://stackoverflow.com/a/6711496/7467189）：只需将“PUT”更改为“修补”。虽然不要求服务器以这种方式解释带有 Content-Range 标头的 PATCH 请求，但这肯定是一种有效的解释，只是不能被任意服务器或客户端依赖。但在像最初的问题这样的情况下，两端都可以控制，这至少是一种显而易见的方法，并且不违反现行标准。

一个额外的考虑因素是 Content-Type 应该表达正在传输的内容，而不是整个实体的内容类型（RFC 给出了这方面的一些示例）。对于以任意块“修补”的内容，这将意味着应用程序/八位字节流，尽管在某些情况下客户端和服务器可能更了解内容并选择将补丁作为具有更具体定义的实体发送（例如多页图像格式的单页）。

Answer 4

使用 Range xxxx-yyyy 标头或 Range xxxx- 标头与 PUT 来更新文件的一部分。它由 Apache 支持。

不要对 RFC 7231 中不能使用 Content-Range 的声明感到困惑。这是为了防止客户端获取从服务器接收的标头并使用 PUT 将它们发送回服务器而造成不良后果。此警告通知与部分 PUT 问题无关。