knox S3 上传损坏或截断的文件答案

【问题标题】：knox S3 upload corrupted or truncated fileknox S3 上传损坏或截断的文件
【发布时间】：2013-06-24 20:22:45
【问题描述】：

这是一个我实际上知道答案的脑筋急转弯问题。我悬赏它，因为它代表了一个有价值的 Node 编程安全提示（这是第一个提示）。

提示 2：在 HTTP 请求中，“Content-Length”标头字段的单位是什么？

我正在使用

var knox = require('knox');
var s3 = knox.createClient({
    key: ...,
    secret: ...,
    bucket: ...
});

// The bug is below:

var stringVal = JSON.stringify(<2d javascript array from a large spreadsheet>)

var req = s3.put(path + filename, {
    'Content-Length': stringVal.length,
    'Content-Type': 'application/json'
});
req.end(stringVal);

生成的上传文件要么被截断，要么以其他方式损坏。我们有stringVal.length === 322889，生成的 S3 项目大小与之匹配。但是下载并重新加载文件会产生一个长度为322140 的字符串。在尝试 JSON.parse 字符串（可预测地）导致语法错误之前，不会出现任何错误。

怎么了？

【问题讨论】：

如果 S3 项目大小与预期相符，则问题一定出在您的下载代码中。请给我看一下好吗？
下载的文件大小也和S3项目大小完全一样。我正在使用 S3-Fox 下载。但是重新加载的字符串长度更小。
好吧，如果不查看所有代码，就很难诊断您的问题。我会尝试从较小的东西开始，看看输入和输出之间是否存在差异。如果没有，它可能是大小问题，尽管我不确定为什么会这样。数字 322140 没有什么神奇之处（特别是不是 2 的幂），所以我怀疑问题出在其他地方。
我有一个忏悔。我实际上知道问题出在哪里，并将其作为问题发布，因为这是我很长时间以来遇到的最微妙的错误之一。您需要的所有代码都在问题中。我花了半天时间把问题缩小到这个范围，但在那之后的几个小时里我仍然感到困惑。提示：Node 为什么要实现“Buffer”类型？
啊。好吧，根据您的提示，这一定是编码问题，因为 Node 实现 Buffer 对象的原因是为了处理不一定是 Unicode 的二进制日期。不幸的是，我看不清楚正确的答案，所以我会让其他人从这里开始运行......期待看到答案。

标签： javascript node.js file-upload amazon-s3 knox-amazon-s3-client

【解决方案1】：

从knox-module (https://github.com/LearnBoost/knox/blob/master/lib/client.js) 的源代码中，您可以了解到它使用标准的http-requests。

req.write 和 req.end 默认从 'utf8' 转换字符串 (http://nodejs.org/api/http.html#http_request_end_data_encoding)。

所以真正发生的是，您通过设置字符串长度而不是“内容长度”字段中的字节数意外切断了字符串的结尾。服务器扔掉所有东西的时间比这更长；所以当你解析字符串时，你会得到一个错误。

最快的解决方法是：

'Content-Length': new Buffer(stringVal).length,

甚至更快：只需删除“Content-Length”行。

【讨论】：

我们赢了！感谢参与！正如您所指出的，他的安全提示是内容长度以字节为单位，而字符串长度以字符为单位。字符并不总是一个字节。