Rails 4 redirects to 'data:,' in Chrome
I've been googling it and found that editing posts with an iframe in Rails 4.0 causes a redirect to "data:,"
Rails 4 now sets the X-XSS-Protection header for all requests, so the iframe trips up the XSS protection in Chrome after a form submit. (https://github.com/elektronaut/sugar/issues/41#issuecomment-25987368)
Solution, add it to your controller:
before_filter :disable_xss_protectionprotecteddef 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
Ok I think I know what this is. You can specify images and text inside a data: protocol, and I believe Chrome is seeing escaped HTML and thinking it is data. Since the mime type is not specified, it leaves the mime type blank after the colon, and just prints the comma.
http://guides.rubyonrails.org/security.html#redirection
Rails 4 automatically escapes HTML, so if you are trying to render HTML, you have to indicate not to escape it. Look at the options for render:
http://guides.rubyonrails.org/security.html#redirection
You can use raw() to render direct HTML.
I'm not convinced it is related to a mimetype issue. I have this issue when a user posts a blog entry that has iframes in its content. When the entry is saved it redirects to the "show" action which will have the user's content (raw/html_safe). Chrome will display the page for a split second and then for some reason re-direct again to the blank "data:," page (in history it will only leave the data:, and the submit page).
here are the response headers i registered:
Ruby 2.0.0 / Rails 4 migrated app with incorrect behavior (staging server)
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=blockRuby 1.8.7 / Rails 2 app with correct behavior (prod server)
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: gzipalso tried having this as the initial html:
<!DOCTYPE html> <html> <head>...and also just (as random tests to detect what could be wrong)
<!DOCTYPE html> <head>...All I know is that if the submitted content has iframes, when redirecting to the blog "display" page chrome's weird behavior kicks in.