Question

我已经尝试了所有的东西，但我的想法已经不多了。请帮忙。

我们在AWS中使用运行Ruby 2.4（Puma）的64位Amazon Linux 2017.09 v2.7.1部署了Elastic Beanstalks。在它们上运行的是Nginx 1.12.1和Rails 5。

在控制器中，我从API下载PDF然后尝试发送它。

data = API::StatementPDF.new(id: params[:id]).result
    send_data data.force_encoding('BINARY'),
              :filename => "statement.pdf",
              :type => "application/pdf",
              :disposition => "attachment",
              stream: 'true',
              buffer_size: '4096',
              :x_sendfile => true

我曾尝试使用force_encoding，buffer_size，x_sendfile。尝试将缓冲区大小增加到大量。试图在.ebextensions/nginx/conf.d/nginx-extensions.conf

中禁用nginx中的gzip

# Configure GZIP compression
gzip              off;
gzip_min_length   1100;
gzip_types        application/pdf;
gzip_vary         on;

但无论我做什么，PDF都会破坏，如果我在文本编辑器中打开文件，许多字符都没有被正确编码。

左边是工作PDF，右边是Beanstalk / Rails / Nginx服务器发送的PDF文件。

在本地运行rails服务器时，PDF会很顺利。将静态PDF添加到应用程序并提供服务也会导致文件损坏。

send_file "#{Rails.root}/app/assets/statement.pdf", type: "application/pdf", x_sendfile: true

...所以我确信这是Nginx，Puma或Elastic Beanstalk的问题。请帮忙。

Answer 1

问题最终出现在API网关上。

Ruby on Rails
Puma
NGINX
API网关

我没想到NGINX过去了。

Answer 2

NGINX真的不会对二进制文件的编码做任何奇怪的事情。

此外，这也不太可能与http://nginx.org/r/gzip相关，因为gzip压缩是在HTTP protocol level上完成的（Accept-Encoding in requests和{{3}并且，结果下载应该在HTTP上下文之外进行解压缩（与下载中不包含HTTP头的方式相同）。

最后，尽管可能不适用于statement.pdf（可能是用户特定的一次性使用语句，其大小与平均网页相当），通过代理服务可下载二进制文件的最佳做法服务器将使用代理服务器的 X-Accel-Redirect 特殊处理，由Content-Encoding in responses和http://nginx.org/r/proxy_ignore_headers完全支持nginx，消除了额外的瓶颈和服务效率低下直接使用实际后端的大文件。

PDF损坏的Rails 5，Nginx，ElasticBeanstalk

2 个答案: