6

我目前正在开发一个大小很重要的 API：我希望答案包含尽可能少的字节。我优化了我的 JSON 答案，但 rails 仍然响应许多奇怪的标题

HTTP/1.1 200 OK
Server: nginx/0.7.67                            # Not from Rails, so ok.
Date: Wed, 25 Apr 2012 20:17:21 GMT             # Date does not matter. We use ETag Can I remove this?
ETag: "678ff0c6074b9456832a710a3cab8e22"        # Needed.
Content-Type: application/json; charset=utf-8   # Also needed.
Transfer-Encoding: chunked                      # The alternative would be Content-Length, so ok.
Connection: keep-alive                          # Good, less TCP overhead.
Status: 200 OK                                  # Redundant! How can I remove this?
X-UA-Compatible: IE=Edge,chrome=1               # Completely unneded.
Cache-Control: no-cache                         # Not needed.
X-Request-Id: c468ce87bb6969541c74f6ea761bce27  # Not a real header at all.
X-Runtime: 0.001376                             # Same goes for this
X-Rack-Cache: invalidate, pass                  # And this.

所以有很多不必要的 HTTP 标头。我可以在我的服务器（nginx）中过滤它们，但是有没有办法直接在 rails 中阻止它？

4

3 回答 3

11

你可以用一个 Rack 中间件来做到这一点。请参阅https://gist.github.com/02c1cc8ce504033d61bf以获取合二为一的示例。

将其添加到您的应用配置时，请使用类似config.middleware.insert_before(ActionDispatch::Static, ::HeaderDelete)

您想在运行时显示的列表中的第一项之前插入它rake middleware，在我的例子中是ActionDispatch::Static。

如果您之前没有在 Rails 上下文中接触过 Rack， http: //guides.rubyonrails.org/rails_on_rack.html可能会有所帮助。

于 2012-04-25T21:43:35.557 回答
9

由于您使用的是 Nginx，另一个选择是HttpHeadersMoreModule。这将允许您精确控制通过线路发送的标头。

在您的情况下，您特别希望使用more_clear_headers指令，例如：

more_clear_headers Server Date Status X-UA-Compatible Cache-Control X-Request-Id X-Runtime X-Rack-Cache;

这也清除了Server标头，因为它并不是真正需要的，如果您尝试保存字节，每一点都会有所帮助。

这个模块确实需要你自己编译 Nginx，但这真的不应该吓到你。Nginx 非常容易编译，只需按照安装说明进行即可。

于 2012-07-09T07:17:56.110 回答
0

x1a4我同意和提出的两种解决方案Stephen McCarth都很好。

理想情况下，HttpHeadersMoreModule如果有人像我一样喜欢带有安全更新的本机 Ubuntu NginX 软件包（或者你没有时间，或者只是懒惰），那么你绝对应该使用它，你不需要这样做。

另一种方法是使用proxy_hide_header

server {

  location @unicorn {

    # ...
    proxy_hide_header X-Powered-By;
    proxy_hide_header X-Runtime;
    # ...
  }
}

注意：@unicorn只是上游服务器，位置可以是任何东西/，，，/assets..

现在反对该解决方案的一个论点是，如果您在配置中使用多个服务器块，您需要proxy_hide_header为每个块指定它们。是的，但是您可以创建文件并包含它

# /etc/nginx/sites-enabled/my_app
server {

  location @unicorn {

    # ...
    include /etc/nginx/shared/stealth_headers
    # ...
  }
}

# /etc/nginx/shared/stealth_headers
proxy_hide_header X-Powered-By;
proxy_hide_header X-Runtime

那么为什么我认为这个解决方案比使用中间件解决方案更好x1a4？

我之前有类似的中间件解决方案，几个月来它运行良好。然后有一天，我们通过异常监控工具party_foul gem停止接收异常错误。长话短说中间件很棘手，我们做了一些代码更改，这个中间件正在抛出异常，但它抛出的异常没有被假定监视异常的中间件捕获。所以是的，整件事都是我的错，我应该更好地关注我的代码，不要做愚蠢的事情，不管我有过难以消除的不愉快经历，所以我只是建议你是否可以在 NginX 级别上处理这个问题，不在中间件级别

+ 如果您的 NginX 正在处理多个配置，则更有意义（如果有一些更改，您不必更新多个应用程序）

于 2014-11-27T16:21:55.433 回答