Actions
Bug #945
closedX-Sendfile Bug in 1.5.0-r1477?
Status:
Fixed
Priority:
Normal
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:
Description
I am not sure if it is just a config failure or if there is a bug in the current X-Sendfile implementation.
It seems that mod_proxy_core set's the sess->do_internal_redirect, returns HANDLER_COMEBACK, then the TRACE prints an error and set's the CON_STATE_ERROR and jumps to the begin of the while. Then it resets the connection, sets CON_STATE_CLOSE.
The last steps which were done are CON_STATE_CONNECT, done is set to 1 and nothing more happens...
Any idea?
Files
Updated by Terminar almost 18 years ago
temporary patch for this contained in #953
Updated by egill almost 18 years ago
I applied the temporary patch with the following result:
mod_proxy_core.c.1443: (trace) handling it in mod_proxy_core: physical.path=/www/sites/dev.site.com/pages/dl.php 2007-01-07 09:52:46: (response.c.629) -- subrequest finished 2007-01-07 09:52:46: (response.c.465) -- handling physical path 2007-01-07 09:52:46: (response.c.466) Path : /www/sites/dev.site.com/pages/file.mp3 2007-01-07 09:52:46: (response.c.473) -- file found 2007-01-07 09:52:46: (response.c.474) Path : /www/sites/dev.site.com/pages/file.mp3 2007-01-07 09:52:46: (response.c.617) -- handling subrequest 2007-01-07 09:52:46: (response.c.618) Path : /www/sites/dev.site.com/pages/file.mp3 2007-01-07 09:52:46: (mod_staticfile.c.352) -- handling file as static file 2007-01-07 09:52:46: (response.c.629) -- subrequest finished 2007-01-07 09:52:46: (response.c.114) Response-Header: HTTP/1.1 200 OK X-Powered-By: PHP/5.2.0 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Content-Encoding: gzip Vary: Accept-Encoding Content-type: text/html ETag: "1390067284" Accept-Ranges: bytes Last-Modified: Sat, 06 Jan 2007 20:13:51 GMT Content-Length: 10270761 Date: Sun, 07 Jan 2007 09:52:46 GMT Server: lighttpd connections.c.823: (error) I thought only READ_REQUEST_* need fdevent-in
Updated by jakabosky almost 18 years ago
- Status changed from New to Fixed
- Resolution set to fixed
re-open if you get this error again:
connections.c.823: (error) I thought only READ_REQUEST_* need fdevent-in
Actions
Also available in: Atom