Accept cookies for analytics, social media, and advertising, or learn more and adjust your preferences. These cookies are on by default for visitors outside the UK and EEA. Privacy Notice.
This feature is documented in standard format here: X-Accel
The delivery of a static file which depends on an application header is known as the X-Sendfile feature.
Lighttpd has this feature and there is a mod_xsendfile for Apache2.
NGINX also has this feature, but implemented a little bit differently. In NGINX this feature is called X-Accel-Redirect
.
There are two main differences:
URI
.should
be defined as internal;
to prevent the client from going directly to the URI.Example NGINX configuration:
location /protected/ {
internal;
root /some/path;
}
If the application adds the header X-Accel-Redirect
for the location /protected/iso.img
:
X-Accel-Redirect: /protected/iso.img
Then NGINX will serve the file /some/path/protected/iso.img
- note that the root and internal redirect paths are concatenated.
If you want to deliver /some/path/iso.img
then configure NGINX like this:
location /protected/ {
internal;
alias /some/path/; # note the trailing slash
}
Note that the following HTTP headers aren’t modified
by NGINX:
Content-Type
Content-Disposition
Accept-Ranges
Set-Cookie
Cache-Control
Expires
If some of these header lines are not set, then they will be set by the redirected response.
The application can also have some control over the process, sending the following headers prior to X-Accel-Redirect.
X-Accel-Limit-Rate: 1024
X-Accel-Buffering: yes|no
X-Accel-Charset: utf-8