X-Sendfile 6
... or the hidden secrets of lighty.
X-Sendfile is one of the important, but mostly unknown features. Time to put the spot-light on it and see why you want to use it.
X-Sendfile is a special header option you can set in any FastCGI backend to tell lighty to ignore the content of the response and replace it by the file that is specified in the X-Sendfile header.
Doesn’t sound dramatic in the first place, but if you spin the idea on some use-cases you will see why this is a good idea:
“you are using a application based authentication before you grant access to files on your server. As you don’t want to allow to fetch the files by non-authed users you have to place them into folder which is not accessable from the document-root. In your application you are streaming the file (let’s say 200Mb each) to the server which forwards it to the client.”
But wait: you are basicly sending a large static file. That’s lighty’s job. That’s what it can do best.
X-Sendfile is exactly doing that. You tell lighty to send the static file as response. All the response headers from the backend are forwarded, just Content-Length is added.
As result your whole application will use alot less memory, will be several times faster and you spend less time in optimizing your application.
To use it you have to load mod_fastcgi and set the option “allow-x-sendfile” in the fastcgi.server configuration. By default X-Sendfile is disabled as it allows to send any file that the webserver has access too. In short: only use it in controled environments.
Trackbacks
Use the following link to trackback from your own site:
http://blog.lighttpd.net/articles/trackback/1740
Comments
-
a basic example would be helpfull. how to use it in an enviroment where you want to specify the files dynamicaly and you got more than one file? just curious because the the php example on the wiki looks so static
-
Wow, this sounds really good. Is there a way to check if X-Sendfile is available from the fastcgi application? Eg. Is there some environment variable to check? Also does it handle partial requests?
-
The docs specify "allow-x-send-file". Is "allow-x-sendfile" the correct option? I love the idea of this header and understood its advantages immediately. But I am testing lighttpd with SCGI, and neither option seems to work, even SCGI is supposed to be based on the FastCGI code. Here's my SCGI config: scgi.server = ("/" = (( "socket" = "/tmp/scgi.socket", "allow-x-send-file" = "enable", "allow-x-sendfile" = "enable", "check-local" = "disable" )) ) Yes, I pass ALL requests to the SCGI app. I send the following back to lighttpd: BEGIN X-Sendfile: /app/docroot/eki/FAQ.html X-LIGHTTPD-send-file: /app/docroot/eki/FAQ.html Content-Type: text/plain Hello! END The X-Sendfile header is passed through to the browser. The X-LIGHTTPD-send-file header is eaten by lighttpd. But I don't get the FAQ.html file. I just get the "Hello!" in the body.
-
I did check the mod_scgi source, and it must have forked before the sendfile feature was added, because it's not there at all. I tried adding it in, because mod_fastcgi and mod_scgi are very similar, and was nearly successful, but the differences are enough that in the one place that matters, I couldn't figure out how to process the header.
-
Very nice feature, but it's definitely need to be compatible with range requests for resumable downloads.
-
Range, ETag, Compression ... is all added now in mod_proxy_core. See http://blog.lighttpd.net/articles/2006/07/22/mod_proxy_core-got-x-sendfile-support