Welcome! Log In Create A New Profile


Re: X-Accel-Redirect testing

September 26, 2012 05:12AM
On Sep 26, 2012, at 1:03 PM, António P. P. Almeida wrote:

> 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.

Some big users are even doing fancy "hybrid cloud" with nginx this way :)

In such scenarios they might have an application on premises and the content on Amazon S3 (or vice versa). Instead of doing usual HTTP redirect to AWS and keeping another part of application on Amazon to retrieve and serve content to the clients, such installations rely on internal redirection/secure retrieval.

Some of them chose to deploy nginx just because of how this particular feature works.

> HTH,
> --- appa
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

AA @ nginx

nginx mailing list
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: 77
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