Internal Redirect

Web server internal redirect via backend response header, aka X-Sendfile or X-Accel-Redirect, is a feature used by some web backend developers and popularized by Ruby on Rails.

The backend process, instead of returning a full HTTP page response back, return only a pointer to a local path.

When the web server receive this special url location pointer via a header variable, the web server will output the content of the specified path, rather than the response from the backend process.

The end user is not aware of this internal redirection and the data returns appears from the original url.

To get this to work on LiteSpeed, just use a simple header “X-LiteSpeed-Location”.

In the return response, follow the directions below:

1. Return a normal “Location” header without “http://domain”, just the URL without the hostname part.
2. Do not set a “Status” header in response. Make sure no “Status” header is returned.
3. PHP always adds “Status” header automatically when a “Location” header was set, we added a special header “X-LiteSpeed-Location” in 3.0.2 to address this, just use it in the same way as a “Location” header. For example, just put a line like below to the php script:

  X-LiteSpeed-Location: /path/to/file_to_be_redirected

That's it folks. LiteSpeed will take over the the rest, perform an internal redirect, and send back the file with sendfile() support if the url points to a static file.

A short example on how to use Internal Redirect for sending files within a RoR Controller. Below is a sendfile function that can be attached to any action.

def sendfile
  @name = session[:filename]                 # a session variable set in a view or other function
  filename = "public/download/" + @name      # create the URI, must be under /public     
  headers["Location"] = filename             # set the 'Location header
  redirect_to(filename)                      # redirect
end

Unlike X-Sendfile or X-Accel-Redirect implementation in other web servers, LiteSpeed uses a URL instead of file path for security reasons. In this way, only file under document root of a virtual host or a Context can be returned, otherwise, it could be a huge security issue if for some reason, either tricked or intentionally, the script sent back a header “X-Sendfile: /../etc/./passwd%00” or something like that, user accounts on your server is no longer a secret.

If you want to prevent user from access the file directly, just use a hard to guess URL like “/you_never_know/where_file_is_stored/…”, or you can use a rewrite rule (in httpd.conf) to deny direct access to the directory holding the files, something like

RewriteCond %{ORG_REQ_URI} ^/blocked/uri/
RewriteRule ^/blocked/uri/ - [R=403,F]

Here is a version in .htaccess (notice the difference between ^/blocked… and ^blocked…)

RewriteCond %{ORG_REQ_URI} ^/blocked/uri/
RewriteRule ^blocked/uri/ - [R=403,F]

%{ORG_REQ_URI} is a LiteSpeed specific rewrite variable, which refers to the URI in the original request header.

Another advantage of our internal redirect implementation is that it does not limited to sending static files, it can be used to pass the request to another script for further processing.