用于 PUT（直接上传）操作的 S3 REST 是否分块？

Question

在 S3 REST API 中，PUT 操作（即直接上传而不是分段上传）如何通过 HTTP 准确发送对如此大文件（即千兆字节）的请求？直接上传是否也分块（如分段上传）并在内部具有定义的大小？

当尝试使用 S3 REST API 进行 PUT（直接上传）操作时，我可以上传的最大容量约为 5GB，这甚至是亚马逊所说的直接上传的最大限制。但是，当尝试上传大于限制的文件时，它会引发异常“您建议的上传超出了允许的最大大小”，并且还会返回 HTTP 响应，其中标头标签“传输编码”为“分块”。

Answer 1

这是来自 S3 的随机选择的错误响应。

< HTTP/1.1 412 Precondition Failed
< x-amz-request-id: 207CAFB3CEXAMPLE
< x-amz-id-2: EXAMPLE/DCHbRTTnpavsMQIg/KRRnoEXAMPLEBJQrqR1TuaRy0SHEXAMPLE5otPHRZw4EXAMPLE=
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Date: Fri, 23 Jun 2017 19:51:52 GMT
< Server: AmazonS3
<
<?xml version="1.0" encoding="UTF-8"?>
<Error><Code>...

Transfer-Encoding: chunked 响应标头仅表示 错误响应正文 S3 正在发送回您将使用分块传输编码。

这与允许上传的内容无关，并且在 HTTP 事务的任一方向（请求或响应）中是否存在 Transfer-Encoding: chunked 与它在相反方向是否存在或支持无关。

PUT 对象 REST API 调用不支持 请求 上的 Transfer-Encoding: chunked。它在请求标头中需要Content-Length:，这会阻止使用分块传输编码。

在标准上传中在 HTTP 层不涉及分块、阻塞等机制——没有有意义的内部结构“part-size”，因为没有部分：它是一个完整的未编码八位字节的连续 TCP 流，长度正好为 Content-Length（八位字节数/字节数），重试和网络错误由 TCP 处理，而 HTTP 不知道这些机制。

如果您发送的 Content-Length 标头超过了允许的最大上传量，您会收到有关建议的上传量超过允许的最大大小的错误消息。如果在 S3 接收到 Content-Length 个八位字节之前意外或故意切断连接，则上传的数据将被丢弃，因为部分对象永远不会创建。