Bug #581
closedX-LIGHTTPD-send-file generating blank page on FreeBSD
Description
I have the following code
"
header('X-LIGHTTPD-send-file: /tmp/test.txt');
?>
test page
"
Th trouble is ... if the path to the file is correct, all I get is a
blank page, no errors to the server error log or the php error log. If I
change the path to a bogus one .. it prints "test page". I have it so
the file is owned by the webserver user and is readable, not sure what's
going on. And yes I have "allow-x-send-file" => "enable" set.
This is only occuring on a FreeBSD 5.3 system, the identical setup with the same config is working well on Redhat.
Files
Updated by pwerbrouck almost 19 years ago
I have the same exact behaviour on a debian (kernel 2.6.8-3-686-smp) box with lighttpd 1.4.11 and fastcgi php 4.4.2-0.dotdeb.1.
Updated by Anonymous over 18 years ago
Hi,
I also have the exact same behaviour:
lighttp 1.4.11 - PHP/5.1.6 on RedHat
-- fabriced
Updated by Anonymous over 18 years ago
Same behavior on lighttpd-1.4.11-1.fc4, AMD64 Fedora Core 4.
strace attached to ticket.
strace edit notes:
Removed RSA keys :)
Deleted extraneous epoll_wait states
Usage notes:
Created file "test.txt"
----
"sendfile succeeded"
----
Two calls to the same PHP script, 'sftest.php',
----
header("X-LIGHTTPD-send-file: /path/to/test.txt");
?>
This is a test page.
-----
First execution - no output.
Changed target directory to /path/to/test1.txt (Non-existent)
Second execution - "This is a test page".
-- jmy
Updated by jan over 18 years ago
- Status changed from New to Fixed
- Resolution set to invalid
After checking the strace the cause is obvious:
1st response is:
11:40:16.438902 writev(12, [{"HTTP/1.1 200 OK\r\nConnection: close\r\nX-Powered-By: PHP/5.1.6\r\nContent-Encoding: gzip\r\nVary: Accept-Encoding\r\nContent-typ
e: text/html\r\nContent-Length: 21\r\nDate: Fri, 22 Sep 2006 15:40:16 GMT\r\nServer: MGC Card Server\r\n\r\n", 217}], 1) = 217
11:40:16.438997 open("/home/mgc/card/test.txt", O_RDONLY) = 13
11:40:16.439050 fcntl(13, F_SETFD, FD_CLOEXEC) = 0
11:40:16.439091 sendfile(12, 13, [0], 21) = 21
11:40:16.439140 close(13) = 0
11:40:16.439179 writev(12, [{"", 0}], 1) = 0
11:40:16.439223 setsockopt(12, SOL_TCP, TCP_CORK, [0], 4) = 0
You see, the file is opened and sent (all 21 bytes).
If you take the look at the headers which are sent, you see:
HTTP/1.1 200 OK Connection: close X-Powered-By: PHP/5.1.6 Content-Encoding: gzip Vary: Accept-Encoding Content-type: text/html Content-Length: 21 Date: Fri, 22 Sep 2006 15:40:16 GMT Server: MGC Card Server
Do you see then "Content-Encoding: gzip" ? PHP controll ALL headers that are sent with the content. You are sending uncompressed content but your PHP is announcing a compression. The browsers will just discard the content as it the compression is "broken".
The second request goes to a not-existing file and the content is forwarded (ignoring the X-...send-file header) from PHP. (php compresses the content which matches the headers).
lighty can't know if the Content-Encoding: header is right or wrong, it trusts the backend. Disabling compression for files using X-...-send-file should fix the issue.
Updated by Anonymous over 18 years ago
this makes complete sense! thanks for the help.
Maybe an update to the documentation would be helpful :-)
-- fabrice
Also available in: Atom