Project

General

Profile

Actions

Bug #1678

closed

broken x-rewrite

Added by tx over 16 years ago. Updated about 15 years ago.

Status:
Fixed
Priority:
Normal
Category:
mod_proxy_core
Target version:
ASK QUESTIONS IN Forums:

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

fix-x-rewrite.diff (976 Bytes) fix-x-rewrite.diff patch for fixing broken x-rewrite -- ytht.net Anonymous, 2008-10-06 13:02
Actions #1

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

Actions #2

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.

Actions #3

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.

Actions #4

Updated by tx about 15 years ago

I can confirm the patch fixes this bug

Actions #5

Updated by stbuehler about 15 years ago

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

Applied in changeset r2672.

Actions

Also available in: Atom