I'm seeing the following when pushing to Heroku:

Configure Rails 3 to disable x-sendfile
Installing rails3_disable_x_sendfile... done

What is this about? Is there a way I should configure my app to avoid seeing
this message?

Hi Trevor,

config/environments/production.rb line 12

  # Specifies the header that your server uses for sending files
  # config.action_dispatch.x_sendfile_header = "X-Sendfile"

  # For nginx:
  # config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect'

  # If you have no front-end server that supports something like X-Sendfile,
  # just comment this out and Rails will serve the files

And while you are in there,
you may want to tweak

config.serve_static_assets = true

Best of luck,
Keenan

On Mar 21, 2011, at 7:20 AM, Trevor Turk wrote:

I have:

config.serve_static_assets = true

...but I don't have anything with:

config.action_dispatch.x_sendfile_header

...at all. Perhaps you are doing something unnecessarily in my case? You can
view my app "teamlab" yourself on Heroku if you like. I can file a support
ticket if necessarily.

Also, you didn't answer my first question: "what is this about" ? :)

Thanks,
- Trevor

Web servers (e.g.: Apache) is tuned for serving up static files.
Ruby (e.g.: mongrel) is not as efficient at serving up static files.

But sometimes, your ruby code generates a file that needs to be streamed. Or it uses logic to determine the name of an existing file that needs to be streamed.

So there is a mechanism for ruby to set a header (X-sendfile), asking apache to stream the file for it.

This is nice:
a) A mongrel is not held up
b) c code can stream a file better than ruby.
c) web servers are often tuned to use OS level calls, zero copy streaming, and stuff. Have them maintain that configuration.

I think lighttpd introduced the flag, but I digress.

You run into a problem when the static file is not on the filesystem of the apache server.
E.g.: Apache is on one server and a mongrel is running on a separate machine.

So you need to tell rails to not use the handy X-sendfile header and stream the file through.

How this affects Heroku?

The web server is running on a different machine than the dynos. So X-sendfile doesn't work.
So they modify your environments/production.rb to disable that feature.

But this tweaking takes a few seconds during slug generation, and they are tweaking your configuration. So they give you a warning to let you know.

At least, that is my take,
Keenan

On Mar 21, 2011, at 7:45 AM, Trevor Turk wrote:

I'll follow up with Heroku directly about it.

- Trevor

Keenan is right in that Heroku doesn't support the X-sendfile method:

- http://devcenter.heroku.com/articles/rack-sendfile

The support team initially added this documentation last year after I
submitted an issue regarding problems I was having serving Sass-
generated files from `./tmp` using Rack::Static. The relevant part of
my Rails configuration looked like this:

    Sass::Plugin.options[:template_location] = {
    "#{Rails.root}/app/stylesheets" => "#{Rails.root}/tmp/stylesheets"
    }

    Rails.configuration.middleware.insert_after 'Sass::Plugin::Rack',
      'Rack::Static', :urls => ['/stylesheets'], :root =>
"#{Rails.root}/tmp"

This worked in a simple Rack app, but not in Rails--I kept getting a
503 error. A member of the Heroku support team suggested that I remove
Rack::Sendfile from my middleware stack, and that solved the issue.
Since Rack::Static delegates to Rack::File, Rack::Sendfile will add
the `X-Sendfile` header. And since Heroku doesn't support the use of
Rack::Sendfile, file downloads will fail.

When I first found about this, I just removed Rack::Sendfile from my
middleware stack, but it seems Heroku is now getting round this
automatically by configuring Rails to disable the `X-Sendfile` header.