Rails 4重定向到Chrome中的“data：”

Google Chrome中存在一种奇怪的行为，此问题也有描述： rails重定向到’data：，’

当创建新资源并且我的控制器重定向到show动作时， chrome 'data:,'在地址栏中启动加载'data:,'的空白页面 。 提出上述问题的作者的答复如下：

这是一项安全function，新页面的HTML内容与Chrome阻止的提交表单的HTML内容相匹配。

但是没有解释如何解决它。 该行为仅出现在Chrome浏览器中。

Answer 1

我一直在谷歌搜索它，发现在Rails 4.0中使用iframe编辑post会导致重定向到“data：”

Rails 4现在为所有请求设置X-XSS-Protection标头，因此iframe在表单提交后启动了Chrome中的XSS保护。 （ https://github.com/elektronaut/sugar/issues/41#issuecomment-25987368 ）

解决方案，将其添加到您的控制器：

 before_filter :disable_xss_protection protected def disable_xss_protection # Disabling this is probably not a good idea, # but the header causes Chrome to choke when being # redirected back after a submit and the page contains an iframe. response.headers['X-XSS-Protection'] = "0" end 

Answer 2

好的，我想我知道这是什么。 您可以在数据：协议中指定图像和文本，我相信Chrome会看到转义的HTML并认为它是数据。 由于未指定mime类型，因此在冒号后将mime类型留空，只打印逗号。

http://guides.rubyonrails.org/security.html#redirection

Rails 4自动转义HTML，因此如果您尝试呈现HTML，则必须指示不要转义它。 查看渲染选项：

http://guides.rubyonrails.org/security.html#redirection

您可以使用raw()来呈现直接HTML。

http://www.webbydude.com/posts/9-the-h-helper-in-rails-3

Answer 3

我不相信它与mimetype问题有关。 当用户发布其内容中包含iframe的博客条目时，我遇到此问题。 保存条目后，它会重定向到“show”操作，该操作将包含用户的内容（raw / html_safe）。 Chrome会在一瞬间显示该页面，然后由于某种原因再次重新指向空白的“data：，”页面（在历史记录中它只会保留数据：和提交页面）。

这是我注册的响应标题：

Ruby 2.0.0 / Rails 4迁移的应用程序行为不正确（登台服务器）

Cache-Control:max-age=0, no-cache, no-store Cache-Control:max-age=0, private, must-revalidate Connection:Keep-Alive Content-Encoding:gzip Content-Length:25359 Content-Type:text/html; charset=utf-8 Date:Thu, 23 Jan 2014 16:37:11 GMT ETag:"6d9d4961ea2df12de67f8a92c43579fb" Server:Apache Set-Cookie: _**********_session_dev=1774518c571bf4e65189d607b276e65e; domain=*********.com; path=/; expires=Thu, 23 Jan 2014 18:37:11 -0000; HttpOnly Status:200 OK Vary:Accept-Encoding X-Content-Type-Options:nosniff X-Frame-Options:SAMEORIGIN X-Mod-Pagespeed:1.6.29.7-3566 X-Request-Id:9f5314a5-ad01-4aec-bd0f-04e8afd9bdac X-UA-Compatible:chrome=1 X-XSS-Protection:1; mode=block
Cache-Control:max-age=0, no-cache, no-store Cache-Control:max-age=0, private, must-revalidate Connection:Keep-Alive Content-Encoding:gzip Content-Length:25359 Content-Type:text/html; charset=utf-8 Date:Thu, 23 Jan 2014 16:37:11 GMT ETag:"6d9d4961ea2df12de67f8a92c43579fb" Server:Apache Set-Cookie: _**********_session_dev=1774518c571bf4e65189d607b276e65e; domain=*********.com; path=/; expires=Thu, 23 Jan 2014 18:37:11 -0000; HttpOnly Status:200 OK Vary:Accept-Encoding X-Content-Type-Options:nosniff X-Frame-Options:SAMEORIGIN X-Mod-Pagespeed:1.6.29.7-3566 X-Request-Id:9f5314a5-ad01-4aec-bd0f-04e8afd9bdac X-UA-Compatible:chrome=1 X-XSS-Protection:1; mode=block 

具有正确行为的Ruby 1.8.7 / Rails 2应用程序（prod服务器）

HTTP/1.1 200 OK Date: Thu, 23 Jan 2014 16:32:53 GMT Server: Apache ETag: "f12135ddd373205352f9754328368217" Cache-Control: private, max-age=0, must-revalidate Status: 200 X-Mod-Pagespeed: 1.4.26.5-3533 Cache-Control: max-age=0, no-cache, no-store Vary: Accept-Encoding Content-Length: 27167 X-Cnection: close Content-Type: text/html; charset=utf-8 Connection: Keep-Alive Content-Encoding: gzip
HTTP/1.1 200 OK Date: Thu, 23 Jan 2014 16:32:53 GMT Server: Apache ETag: "f12135ddd373205352f9754328368217" Cache-Control: private, max-age=0, must-revalidate Status: 200 X-Mod-Pagespeed: 1.4.26.5-3533 Cache-Control: max-age=0, no-cache, no-store Vary: Accept-Encoding Content-Length: 27167 X-Cnection: close Content-Type: text/html; charset=utf-8 Connection: Keep-Alive Content-Encoding: gzip 

也尝试将此作为初始html：

  ...
  ... 

而且还是（作为随机测试来检测可能出错的地方）

 ...
 ... 

我所知道的是，如果提交的内容有iframe，当重定向到博客“显示”页面时，chrome的奇怪行为就会开始。