Feature #851

Feature Request: New option "x-send-file-docroot"

Added by Anonymous about 13 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Missing in 1.5.x:


    $file = "/etc/passwd";
            header("Content-Type: text/plain");
            header("X-LIGHTTPD-send-file: ".$file);

Do i need more explanation ?

"allow-x-send-file" => "enable" is a very good feature, but its a little bit too powerful. So, it would be nice to restrict this function to a separate doc-root (or the same as the doc-root of the specific vhosts)

P.S: Excuse my english, i am german (nobody is perfect ;))

-- eebkiller

Associated revisions

Revision b9940f98 (diff)
Added by gstrauss over 3 years ago

[mod_fastcgi] use http_response_xsendfile() (fixes #799, fixes #851, fixes #2017, fixes #2076)

handle X-Sendfile and X-LIGHTTPD-send-file w/ http_response_xsendfile()
if host is configured ( "x-sendfile" = "enable" )

Note: X-Sendfile path is url-decoded for consistency, like X-Sendfile2
(response headers should be url-encoded to avoid tripping over
chars allowed in filesystem but which might change response
header parsing semantics)

Note: deprecated: "allow-x-send-file"; use "x-sendfile"
Note: deprecated: X-LIGHTTPD-send-file header; use X-Sendfile header
Note: deprecated: X-Sendfile2 header; use X-Sendfile header
For now, X-Sendfile2 is still handled internally by mod_fastcgi.

Since http_response_send_file() supports HTTP Range requests,
X-Sendfile2 is effectively obsolete. However, any code, e.g. PHP,
currently using X-Sendfile2 is probably manually generating 206 Partial
Content status and Range response headers. A future version of lighttpd
might remove X-Sendfile2. Existing code should be converted to use
X-Sendfile, which is easily done by removing all the special logic
around using X-Sendfile2, since the 206 Partial Content status and Range
response headers are handled in http_response_send_file().

"mod_fastcgi + X-Sendfile -> mod_staticfile"
"Feature Request: New option "x-send-file-docroot""
"X-Sendfile handoff to mod-static-file in 1.4.x"
"X-sendfile should be able to set content-type"

Revision c380d227
Added by gstrauss over 3 years ago

[mod_cgi,mod_fastcgi,mod_scgi] X-Sendfile features

[core] http_response_send_file() shared code (#2017)
[mod_fastcgi] use http_response_xsendfile()
(fixes #799, fixes #851, fixes #2017, fixes #2076)
[mod_scgi] X-Sendfile feature (fixes #2253)
[mod_cgi] X-Sendfile feature (fixes #2313)

Merge branch 'feature-2017-http_response_send_file' into master

github: closes #59



Updated by darix about 13 years ago

/etc/passwd is more or less not critical. at least on linux. /etc/shadow is more critical. but that should be root only. whoever runs his webserver as root should be shot in the first place.

anyway.... x-sendfile has other problems. what if the user creates a php script that symlinks /etc/shadow into his docroot?

i personally would say: only enable x-sendfile for trusted scripts. on mass hosting environments i would leave it off. And i really wonder if a check like that would put us on the same road as php's open_basedir.

jan do we want that? at the first sight, the code for that looks trivial.


Updated by gstrauss over 3 years ago

  • Description updated (diff)
  • Status changed from New to Patch Pending
  • Assignee deleted (jan)
  • Target version set to 1.4.40

Updated by gstrauss over 3 years ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom