XSendfile¶
この機能は標準の形式でここで説明されています: X-Accel
アプリケーションのヘッダに依存する静的なファイルの配送は X-Sendfile 機能として知られています。
Lighttpd はこの機能を持ち、Apache2についてはmod_xsendfileがあります。
NGINX もこの機能を持ちますが、少し異なって実装されています。NGIXNではこの機能は X-Accel-Redirect
と呼ばれます。
2つの主な違いがあります:
- ヘッダは
URI
を含まなければなりません。 - location は
internal;
として定義されなければなりません
; クライアントが直接URIに行くのを避けるため。
NGINX設定の例:
location /protected/ {
internal;
root /some/path;
}
アプリケーションが/protected/iso.img
のためのヘッダ X-Accel-Redirect を追加します:
X-Accel-Redirect: /protected/iso.img;
そして、NGINXがファイル /some/path/protected/iso.img
を提供するでしょう - rootと内部的なリダイレクトパスが連結されることに注意してください。
/some/path/iso.img
を配送したい場合は、このようにNGINXを設定します:
location /protected/ {
internal;
alias /some/path/; # note the trailing slash
}
以下のHTTPヘッダはNGINXによって修正
されません:
Content-Type
Content-Disposition
Accept-Ranges
Set-Cookie
Cache-Control
Expires
これらのヘッダ行のうちのいくつかが設定されていない場合は、リダイレクトされた応答によって設定されるでしょう。
アプリケーションはX-Accel-Redirectに先立って以下のヘッダを送信して、プロセスに対して幾らかの制御も持ちます。
X-Accel-Limit-Rate: 1024
X-Accel-Buffering: yes|no
X-Accel-Charset: utf-8
この問題へのリンク¶
- Alexey Kovyrinによる(railsとphpの例を使って)制御されたダウンロードの実装のためのNGINXによるX-Accel-Redirect Headerの使用
- Alexey KovyrinによるNginx-Fu: リモートサーバからのX-Accel-Redirect
- X-Accel-Redirectのための Rails 3.x assets pipeline サポート
- proxy_ignore_headers X-Accel-Redirectを使う時のContent Typeヘッダの黙殺
- proxy_hide_header X-Accel-Redirectを使う時のupstreamサーバからのヘッダの隠蔽