class Rack::Sendfile

`Sendfile`¶ ↑

The Sendfile middleware intercepts responses whose body is being served from a file and replaces it with a server specific x-sendfile header. The web server is then responsible for writing the file contents to the client. This can dramatically reduce the amount of work required by the Ruby backend and takes advantage of the web server’s optimized file delivery code.

In order to take advantage of this middleware, the response body must respond to to_path and the request must include an ‘x-sendfile-type` header. Rack::Files and other components implement to_path so there’s rarely anything you need to do in your application. The ‘x-sendfile-type` header is typically set in your web servers configuration. The following sections attempt to document

Nginx¶ ↑

Nginx supports the ‘x-accel-redirect` header. This is similar to `x-sendfile` but requires parts of the filesystem to be mapped into a private URL hierarchy.

The following example shows the Nginx configuration required to create a private “/files/” area, enable ‘x-accel-redirect`, and pass the special `x-accel-mapping` header to the backend:

location ~ /files/(.*) {
  internal;
  alias /var/www/$1;
}

location / {
  proxy_redirect     off;

  proxy_set_header   Host                $host;
  proxy_set_header   X-Real-IP           $remote_addr;
  proxy_set_header   X-Forwarded-For     $proxy_add_x_forwarded_for;

  proxy_set_header   x-accel-mapping     /var/www/=/files/;

  proxy_pass         http://127.0.0.1:8080/;
}

The ‘x-accel-mapping` header should specify the location on the file system, followed by an equals sign (=), followed name of the private URL pattern that it maps to. The middleware performs a simple substitution on the resulting path.

To enable ‘x-accel-redirect`, you must configure the middleware explicitly:

use Rack::Sendfile, "x-accel-redirect"

For security reasons, the ‘x-sendfile-type` header from requests is ignored. The sendfile variation must be set via the middleware constructor.

lighttpd¶ ↑

Lighttpd has supported some variation of the ‘x-sendfile` header for some time, although only recent version support `x-sendfile` in a reverse proxy configuration.

$HTTP["host"] == "example.com" {
   proxy-core.protocol = "http"
   proxy-core.balancer = "round-robin"
   proxy-core.backends = (
     "127.0.0.1:8000",
     "127.0.0.1:8001",
     ...
   )

   proxy-core.allow-x-sendfile = "enable"
   proxy-core.rewrite-request = (
     "x-sendfile-type" => (".*" => "x-sendfile")
   )
 }

Apache¶ ↑

‘x-sendfile` is supported under Apache 2.x using a separate module:

tn123.org/mod_xsendfile/

Once the module is compiled and installed, you can enable it using XSendFile config directive:

RequestHeader Set x-sendfile-type x-sendfile
ProxyPassReverse / http://localhost:8001/
XSendFile on

Mapping parameter¶ ↑

The third parameter allows for an overriding extension of the ‘x-accel-mapping` header. Mappings should be provided in tuples of internal to external. The internal values may contain regular expression syntax, they will be matched with case indifference.

When ‘x-accel-redirect` is explicitly enabled via the variation parameter, and no application-level mappings are provided, the middleware will read the `x-accel-mapping` header from the proxy. This allows nginx to control the path mapping without requiring application-level configuration.

Security¶ ↑

For security reasons, the ‘x-sendfile-type` header from HTTP requests is ignored. The sendfile variation must be explicitly configured via the middleware constructor to prevent information disclosure vulnerabilities where attackers could bypass proxy restrictions.

Public Class Methods

new (app, variation = nil, mappings = [])

Source

# File lib/rack/sendfile.rb, line 122
def initialize(app, variation = nil, mappings = [])
  @app = app
  @variation = variation
  @mappings = mappings.map do |internal, external|
    [/\A#{internal}/i, external]
  end
end

Public Instance Methods

call (env)