Bug #2733
closed
X-LIGHTTPD-send-file return 0 bytes
Added by roytam1 almost 9 years ago.
Updated almost 9 years ago.
Description
The following test PHP can return itself in 1.4.39, but in git HEAD it returns 0 bytes.
Test PHP:
<?php
$xsendfile = 'X-LIGHTTPD-send-file'; // use x-sendfile header?
// 'X-sendfile': for apache mod_xsendfile/lighttpd-1.5
// 'X-LIGHTTPD-send-file': for lighttpd-1.4.20+
// 'X-Accel-Redirect': for nginx
$xendfile_prefix = dirname(__FILE__).'/'; // path prefix for x-sendfile
$fname = 'xsend.php';
$fname_out = 'xsend.txt';
$upfile_type = 'text/plain';
header("Content-Disposition: attachment; filename=$fname_out");
header("Content-Type: $upfile_type; name=$fname_out");
header($xsendfile.': '.$xendfile_prefix.$fname);
- Status changed from New to Patch Pending
Are you using mod_fastcgi or mod_cgi to serve this request? I wasn't able to reproduce this using mod_fastcgi.
Did you make sure that you set "x-sendfile" => "enable" (preferred) or "allow-x-send-file" => "enable" in the lighttpd.conf fastcgi.server definition for the host? If you did not do so, then the X-Sendfile and X-LIGHTTPD-send-file headers will be ignored, and since the PHP example given does not produce a body, the result will be a 0-length body.
For CGI and SCGI, the header is X-Sendfile. For mod_fastcgi, the header is X-Sendfile (preferred), but X-LIGHTTPD-send-file is also honored.
I did find a bug in using X-Sendfile for CGI and SCGI, and will push that one-line fix shortly.
gstrauss wrote:
Are you using mod_fastcgi or mod_cgi to serve this request? I wasn't able to reproduce this using mod_fastcgi.
Did you make sure that you set "x-sendfile" => "enable" (preferred) or "allow-x-send-file" => "enable" in the lighttpd.conf fastcgi.server definition for the host? If you did not do so, then the X-Sendfile and X-LIGHTTPD-send-file headers will be ignored, and since the PHP example given does not produce a body, the result will be a 0-length body.
For CGI and SCGI, the header is X-Sendfile. For mod_fastcgi, the header is X-Sendfile (preferred), but X-LIGHTTPD-send-file is also honored.
I did find a bug in using X-Sendfile for CGI and SCGI, and will push that one-line fix shortly.
Of course I have allow-x-send-file enabled, in 1.4.39 it works flawlessly:
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/var/run/lighttpd/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi",
"allow-x-send-file" => "enable"
)
)
)
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
This fix I pushed for CGI and SCGI use of X-Sendfile will auto-close this ticket, but let's keep working on this ticket. I'll continue to try to repo your issue using mod_fastcgi.
and curl -v show something different:
# curl -v http://localhost/xsend.php
* About to connect() to localhost port 80
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 80
> GET /xsend.php HTTP/1.1
> User-Agent: curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8zh zlib/1.2.3 libidn/0.6.5
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: PHP/5.3.29
< Content-Disposition: attachment; filename=xsend.txt
< Content-Type: text/plain; name=xsend.txt
< Accept-Ranges: bytes
< ETag: "3658205436"
< Last-Modified: Wed, 18 May 2016 02:39:54 GMT
< Transfer-Encoding: chunked
< Date: Wed, 18 May 2016 04:18:26 GMT
< Server: lighttpd/1.4.40
* Received problem 2 in the chunky parser
* Closing connection #0
curl: (56) Received problem 2 in the chunky parser
# curl -v http://localhost/xsend.php
* About to connect() to localhost port 80
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 80
> GET /xsend.php HTTP/1.1
> User-Agent: curl/7.15.5 (i386-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8zh zlib/1.2.3 libidn/0.6.5
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: PHP/5.3.29
< Content-Disposition: attachment; filename=xsend.txt
< Content-Type: text/plain; name=xsend.txt
< Content-Length: 621
< Date: Wed, 18 May 2016 04:18:50 GMT
< Server: lighttpd/1.4.39
<?php
[snip]
- Status changed from Fixed to Reopened
Re-opening. I can repro the chunked error from curl and am looking into that now.
I still can't repro the issue with the HEAD request that you reported.
gstrauss wrote:
Re-opening. I can repro the chunked error from curl and am looking into that now.
I still can't repro the issue with the HEAD request that you reported.
maybe there is difference how browsers handling chunk error by downloading 0 bytes file or not downloading at all.
This patch does not enable Transfer-Encoding: chunked when X-Sendfile is used:
diff --git a/src/mod_fastcgi.c b/src/mod_fastcgi.c
index 52030ba..41f0090 100644
--- a/src/mod_fastcgi.c
+++ b/src/mod_fastcgi.c
@@ -2617,11 +2617,9 @@ static int fcgi_demux_response(server *srv, handler_ctx *hctx) {
}
hctx->send_content_body = 0; /* ignore the content */
- }
-
- /* enable chunked-transfer-encoding */
- if (con->request.http_version == HTTP_VERSION_1_1 &&
+ } else if (con->request.http_version == HTTP_VERSION_1_1 &&
!(con->parsed_response & HTTP_CONTENT_LENGTH)) {
+ /* enable chunked-transfer-encoding */
con->response.transfer_encoding = HTTP_TRANSFER_ENCODING_CHUNKED;
}
}
Well, no file should be downloaded for a HEAD request.
In any case, would you please test the above patch and see if that fixes your issues? It fixes the curl issue that I could reproduce.
simpler patch. same effect
diff --git a/src/mod_fastcgi.c b/src/mod_fastcgi.c
index 52030ba..e92040a 100644
--- a/src/mod_fastcgi.c
+++ b/src/mod_fastcgi.c
@@ -2613,10 +2613,10 @@ static int fcgi_demux_response(server *srv, handler_ctx *hctx) {
http_response_xsendfile(srv, con, ds->value, host->xsendfile_docroot);
if (con->mode == DIRECT) {
fin = 1;
- break;
}
hctx->send_content_body = 0; /* ignore the content */
+ break;
}
/* enable chunked-transfer-encoding */
Pushed above patch. Please re-open ticket if you still have issues. Thanks for working with me to fix these bugs!
- Status changed from Reopened to Fixed
Also available in: Atom