Bug #1678
closedbroken x-rewrite
Description
Hi,
i've found that x-rewrite is somehow broken
example lighty.conf
server.modules = ( "mod_indexfile", "mod_rewrite", "mod_access", "mod_uploadprogress", "mod_auth", "mod_rewrite", "mod_setenv", "mod_accesslog", "mod_proxy_core", "mod_proxy_backend_fastcgi", "mod_proxy_backend_http", "mod_dirlisting", "mod_staticfile", "mod_chunked", # 14 ) server.document-root = "/var/www/" server.errorlog = "/var/log/lighttpd/error.log" server.indexfiles = ("index.php", "index.html", "index.htm", "default.htm") accesslog.filename = "/var/log/lighttpd/access.log" url.access-deny = ("~", ".inc") server.bind = "192.168.0.91" server.pid-file = "/var/run/lighttpd.pid" server.dir-listing = "disable" server.username = "www-data" server.groupname = "www-data" url.rewrite-once = ( "^(.*)" => "/index.php/$1", ) debug.log-request-header = "enable" $PHYSICAL["existing-path"] =~ "\.php$" { # block 1 proxy-core.balancer = "round-robin" proxy-core.protocol = "fastcgi" proxy-core.allow-x-sendfile = "enable" proxy-core.allow-x-rewrite = "enable" proxy-core.backends = ("unix:/tmp/php-fastcgi.sock") proxy-core.max-pool-size = 16 } # end of $PHYSICAL["existing-path"] =~ "\.php$" $HTTP["host"] == "mediaone.bg" { # block 2 proxy-core.balancer = "static" proxy-core.protocol = "http" proxy-core.debug = 1 proxy-core.max-keep-alive-requests = 0 proxy-core.backends = ("193.200.28.22:80") } # end of $HTTP["host"] == "mediaone.bg"
example rewrite file
<? header("X-Rewrite-URI: /"); header("X-Rewrite-Host: mediaone.bg"); header("X-Rewrite-Backend: 193.200.28.22:80"); ?>
and wget output
while true ; do wget -S -vvv -O /dev/null 192.168.0.91 2>&1 | grep Content-Length; done Content-Length: 0 Content-Length: 0 Content-Length: 0 Content-Length: 0 Content-Length: 0 Content-Length: 2157 Content-Length: 2157 Content-Length: 2157 Content-Length: 2157 Content-Length: 2157 Content-Length: 2157 Content-Length: 0 Content-Length: 0 Content-Length: 0 Content-Length: 2157
Not every time we got content, but headers are always returned to the user
I have tested with trunk and with lighttpd.git/stbuehler
with trunk there is an error in error.log
connections.c.1341: (trace) filter[-1] is not empty: 131072 (report me) connections.c.1341: (trace) filter[-1] is not empty: 262144 (report me) connections.c.1341: (trace) filter[-1] is not empty: 377086 (report me) connections.c.1341: (trace) filter[-1] is not empty: 508158 (report me) connections.c.1341: (trace) filter[-1] is not empty: 786686 (report me) connections.c.1341: (trace) filter[-1] is not empty: 1048830 (report me) connections.c.1341: (trace) filter[-1] is not empty: 1327358 (report me)
with lighttpd.git/stbuehler there is no any error in error.log
P.S. proxy-core.debug does not show any useful information
Files
Updated by Anonymous about 16 years ago
It seems con->send->is_closed is set to 1 after the first connect to the backend and is not set to 0 before reconnect another backend.
It will cause that lighttpd think it has finished all job when it only received some
response from the backend.
The patch of the attachment will fix this.
If someone tested this patch or have any problem, please contact me.Thanks.
-- ytht.net
Updated by bewest over 15 years ago
This is a problem for me as well. I get different content-lengths from the same resource. Sometimes the proxied resource is truncated, other times the resource is all jumbled up ( end of document, beginning of document ). Will test this patch to see if it fixes it.
I only see this problem when using the same kind of setup posted by the original reporter:
1.) fast-cgi emits X-REWRITE
2.) Re-dispatches to the http backend proxy
3.) Response is inconsistent: truncated or jumbled.
In my observations, I don't see an all-or-nothing response, as the original poster indicates, but rather several clumps of errors:
$ for x in $( seq 1 100 ); do curl -s "http://EG/rewrite/then/proxy" -o /dev/null --write-out "%{size_download}\n"; done | sort | uniq -c 69 1225 2 259 27 2673 2 4121
Sorry, I have to blank out the exact URI.
Anyway, when I go directly through the proxy, there is no problem. When I use X-Rewrite to go to a local backend there is no problem. The problem only occurs when using mod_proxy_backend_http as the consequence of an X-Rewrite instruction. It doesn't seem to be a problem using the fastcgi proxy backend, only http.
FWIW, I only use X-REWRITE-URI and X-REWRITE-HOST because the backend list is static for me.
Updated by bewest over 15 years ago
- Status changed from New to Patch Pending
My testing indicates that the patch mentioned above applied to trunk as of 2009-08-18 (r2613) fixes this issue. I've been using r2294, a pre-release of 1.5. The patch applied to r2294 does not work.
$ for x in $( seq 1 100 ); do curl -s "http://EG/rewrite/then/proxy" -o /dev/null --write-out "%{size_download}\n"; done | sort | uniq -c 88 9245 11 9341 1 9437
Much Better.
Updated by stbuehler about 15 years ago
- Status changed from Patch Pending to Fixed
- % Done changed from 0 to 100
Applied in changeset r2672.
Also available in: Atom