Я использую Dropbox HTTP API, AWS SDK для Node и request-promise-native для загрузки PDF-файла из папки Dropbox и немедленной загрузки его на S3. Этот код работает в AWS Lambda:
const rp = require('request-promise-native')
const getOptions = {
url: 'https://content.dropboxapi.com/2/files/download',
method: 'GET',
headers: {
'Authorization': `Bearer ${settings.DROPBOX_TOKEN}`,
'Dropbox-API-Arg': JSON.stringify({ path: event.path })
},
gzip: true,
resolveWithFullResponse: true
}
rp(getOptions)
.on('error', callback)
.then((response) => {
const putOptions = {
ACL: 'public-read',
Bucket: 'mybucket',
Key: common.dropboxToS3Path(event.path),
Body: new Buffer(response.body),
ContentDisposition: `inline; filename=\"${path.basename(event.path)}\"`,
ContentEncoding: 'utf-8',
ContentLength: response.headers['content-length'],
ContentType: 'application/pdf'
}
s3.putObject(putOptions, function (err, data) {
callback(err, data)
})
})
.catch((err) => {
callback(err)
})
Заголовки ответа Dropbox имеют ожидаемую длину Content-Length и Content-Disposition, установленную на «вложение», которое я меняю в операции размещения S3.
Полученный файл на S3 почти в два раза больше и не может быть открыт ни одной программой чтения PDF.
Что мне не хватает?
ContentEncoding: 'utf-8'
кажется неправильным: PDF-файлы по своей природе не текстовые, а двоичные, поэтому обработка их как текста в кодировке UTF8 может повредить их. - person mkl   schedule 20.08.2016encoding: null
наgetOptions
в моем образце. - person Seth   schedule 20.08.2016