Capistrano & X-Sendfile
Asked Answered
R

1

4

I'm trying to make X-Sendfile work for serving my heavy attachments with capistrano. I found that X-Sendfile is not working with symlinks. How could I handle the files inside a folder symlinked by Capistrano so?

my web server is apache2 + passenger

in my production.rb:

config.action_dispatch.x_sendfile_header = "X-Sendfile"

in my controller action:

filename = File.join([Rails.root, "private/videos", @lesson.link_video1 + ".mp4"])
response.headers["X-Sendfile"]=  filename
send_file filename, :disposition => :inline, :stream => true, :x_sendfile => true
render nothing: true

my filesystem structure (where a "->" stands for "symlink" and indentation means subfolder):

/var/www/myproject
  releases/
  ....
  current/ -> /var/www/myproject/releases/xxxxxxxxxxxx
    app/
    public/
    private/
      videos/ -> /home/ftp_user/videos

my apache config XSendFile on XSendFilePath / #also tried /home/ftp_user/videos

My application is able to serve small files, but with big ones it gives a NoMemoryError(failed to allocate memory)

I think it's not using x-sendfile, because the behavior is the same if I don't use it.

Here are the response headers of the file i'm trying to serve

Accept-Ranges:bytes
Cache-Control:private
Connection:Keep-Alive
Content-Disposition:inline
Content-Range:bytes 0-1265/980720989
Content-Transfer-Encoding:binary
Content-Type:video/mp4
Date:Sat, 01 Mar 2014 13:24:19 GMT
ETag:"70b7da582d090774f6e42d4e44ae3ba5"
Keep-Alive:timeout=5, max=97
Server:Apache/2.4.6 (Ubuntu)
Status:200 OK
Transfer-Encoding:chunked
X-Content-Type-Options:nosniff
X-Frame-Options:SAMEORIGIN
X-Powered-By:Phusion Passenger 4.0.37
X-Request-Id:22ff0a30-c2fa-43fe-87c6-b9a5e7da12f2
X-Runtime:0.008150
X-UA-Compatible:chrome=1
X-XSS-Protection:1; mode=block

I really don't know how to debug it, if it's a x-sendfile issue or if I'm trying to do something impossible for the symlinks problem

EDIT: Following the suggested answer in the accepted one, it "magically" started working!

I created a capistrano task this way:

 task :storage_links do
    on roles(:web), in: :sequence, wait: 2 do
      #creo i link simbolici alle risorse
      within "/var/www/my_application/current/private" do
        execute :ln, "-nFs", "/home/ftp_user/videos"
      end
    end
  end

I didn't manage to run it after finalize_update, so i run it after the restart, by hand.

And i corrected my apache configuration in this way:

XSendFilePath /var/www/my_application

(before i was pointing x-sendfile to the ftp folder)

In my response headers also now X-Sendfile is not appearing, and i got a 206 - partial content, but everything seems to work and apache is serving files in the right way (also very heavy files).

I know this can be a security issue, but i will try to point it to the last release of my application cause pointing it to the current symlink is not working.

Rafe answered 1/3, 2014 at 13:29 Comment(2)
Curious as to your versions of Rails, Passenger, Apache and X-Sendfile. Also the Type and version of your OS. I had to move to a custom Apache server binary and never did get X-Sendfile working, same issue as yours (not the memory part though as it's always small files), though I always blamed the binary.Sacha
I'm using Rails 4.0.0, Passenger 4.0.37, Apache 2.4.6 on Ubuntu 13.10 (64bit). Hope it helps you.Rafe
H
1

Maybe I found a solution. How did you make your symlinks?

maybe you did ln -s, and it's not enough

Here they suggest using ln -nFs, so he recognizes it's a directory that you are linking in

Hydrozoan answered 10/3, 2014 at 19:0 Comment(3)
Wow this is working now!!! i'll edit my question to explain what changes i made! Thank you so much! You saved my day!Rafe
For me it does not change anything. Apache 2.2 xsendfile 0.12 on debian 7. XSendFile still does not work unless I point PassengerAppRoot to direct location of currently deployed version of application, without symlinks on the path. Obviously it is not consistent with the idea of Capistrano. Any ideas?Ambulatory
I finally made it work. See here: #28860149Ambulatory

© 2022 - 2024 — McMap. All rights reserved.