Welcome! Log In Create A New Profile

Advanced

Re: X-Accel-Redirect testing

António P. P. Almeida
September 26, 2012 05:04AM
On 26 Set 2012 10h17 CEST, nginx-forum@nginx.us wrote:

> Jonathan Matthews Wrote:
> -------------------------------------------------------
>
>> No. This is a /response/ header from (typically) a dynamic backend
>> which instructs nginx to serve some piece of static content, thus
>> freeing up the backend for more intelligent, heavy-weight request
>> handling. There are more sophisticated uses, but you should at
>> least understand this basic use case before attempting them.
>
> Hello Jonathan,
>
> Thanks for the reply. I'd love to at least understand the basics, in
> fact this is what I'm trying to do. It's a bit hard when there's no
> thorough documentation and all responses found on internet are
> vague.
>
> You are saying that it will work only when Nginx is a reverse proxy
> and receives a response from another backend, like Apache. But I
> want Apache as frontend and Nginx as backend. Should I focus on
> Xsendfile?

XSendfile in Nginx is called X-Accel-Redirect.

The way X-Accel-Redirect works is that your app/backend sends a
"special" header with the location of the file that is to be served by
Nginx. Usually the application case is for speeding up the delivery of
protected/private files. Let's say you have a ecommerce site that
sells digital downloads. Then these files will be protected and for
speeding up the delivery your application sends an X-Accel-Redirect
header with the location of the file. Then the file is delivered by
Nginx as a regular static file.

Example: I request to download:

http://myshop.com/downloads/big_hit.flac

The file is stocked at /path/to/the/flac_files/big_hit.flac

your ecommerce sends an header:

X-Accel-Redirect: /path/to/the/flac_files/big_hit.flac

when Nginx sees this he knows that now the file is to be served
directly from the file system as a regular static file. Note that the
real location is hidden from the client.

Note that the real location must be protected from direct access by
the client always, be it from your app, be it from your server, for
example using the internal keyword:

http://nginx.org/en/docs/http/ngx_http_core_module.html#internal

In a nutshell that's how it works.

HTH,
--- appa

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Subject Author Posted

X-Accel-Redirect testing

w00t September 25, 2012 06:28PM

Re: X-Accel-Redirect testing

Jonathan Matthews September 25, 2012 07:08PM

Re: X-Accel-Redirect testing

w00t September 26, 2012 04:17AM

Re: X-Accel-Redirect testing

António P. P. Almeida September 26, 2012 05:04AM

Re: X-Accel-Redirect testing

nginxorg September 26, 2012 05:12AM

Re: X-Accel-Redirect testing

w00t October 02, 2012 08:01AM

Re: X-Accel-Redirect testing

António P. P. Almeida October 02, 2012 08:20AM



Sorry, only registered users may post in this forum.

Click here to login

Online Users

Guests: 86
Record Number of Users: 6 on February 13, 2018
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready