X-Accel-Redirect testing

[Andrew Alexeev]

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

> On 26 Set 2012 10h17 CEST, nginx-forum at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx

-- 
AA @ nginx
http://nginx.com/support.html