Периодические ошибки при использовании lighttpd + mod_proxy

Question

Периодические ошибки при использовании lighttpd + mod_proxy

Я использую lighttpd v1.4.18 на встроенном устройстве Linux. Lighty прослушивает порт 80 и служит обратным прокси-сервером, поэтому запросы _http://192.168.0.1/foo1 передаются на _http://127.0.0.1:11111

### 1st appreach
proxy.server = ( "^/foo1" => ( "" => ( "host" => "127.0.0.1", "port" => 11111 )))

### 2nd approach
$HTTP["url"] =~ "^/foo1" { 
    proxy.server = ( "" => (( "host" => "127.0.0.1", "port" => 11111 ))) 
}

В принципе, это работает нормально. Но я случайно сталкиваюсь с 404 ошибками, особенно после запуска. Если фоновая служба "foo1" не работает, я получаю сообщение об ошибке 503, что имеет смысл. Но так как я могу запросить _http://192.168.0.1:11111, это не так... Устройство работает и работает "foo1" готов для обслуживания входящих запросов. Итак, почему эти 404 ошибки возникают с использованием 1-го или 2-го подхода?!

Вот что показывает журнал...

2012-03-05 08:31:36: (request.c.294) fd: 6 request-len: 164 
POST /foo1 HTTP/1.1
Host: 192.168.0.1
User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8
Content-Length: 450
Connection: close
SOAPAction: ""


2012-03-05 08:31:36: (response.c.205) -- splitting Request-URI 
2012-03-05 08:31:36: (response.c.206) Request-URI  :  /foo1
2012-03-05 08:31:36: (response.c.207) URI-scheme   :  http 
2012-03-05 08:31:36: (response.c.208) URI-authority:  192.168.0.1 
2012-03-05 08:31:36: (response.c.209) URI-path     :  /foo1
2012-03-05 08:31:36: (response.c.210) URI-query    :   
2012-03-05 08:31:36: (response.c.260) -- sanatising URI 
2012-03-05 08:31:36: (response.c.261) URI-path     :  /foo1
2012-03-05 08:31:36: (mod_proxy.c.1080) proxy - start 
2012-03-05 08:31:36: (response.c.375) -- before doc_root 
2012-03-05 08:31:36: (response.c.376) Doc-Root     : /var/www 
2012-03-05 08:31:36: (response.c.377) Rel-Path     : /foo1
2012-03-05 08:31:36: (response.c.378) Path         :  
2012-03-05 08:31:36: (response.c.426) -- after doc_root 
2012-03-05 08:31:36: (response.c.427) Doc-Root     : /var/www 
2012-03-05 08:31:36: (response.c.428) Rel-Path     : /foo1
2012-03-05 08:31:36: (response.c.429) Path         : /var/www/foo1
2012-03-05 08:31:36: (response.c.446) -- logical -> physical 
2012-03-05 08:31:36: (response.c.447) Doc-Root     : /var/www 
2012-03-05 08:31:36: (response.c.448) Rel-Path     : /foo1
2012-03-05 08:31:36: (response.c.449) Path         : /var/www/foo1
2012-03-05 08:31:36: (response.c.466) -- handling physical path 
2012-03-05 08:31:36: (response.c.467) Path         : /var/www/foo1
2012-03-05 08:31:36: (response.c.523) -- file not found 
2012-03-05 08:31:36: (response.c.524) Path         : /var/www/foo1
2012-03-05 08:31:36: (response.c.114) Response-Header: 
HTTP/1.1 404 Not Found
Connection: close
Content-Type: text/html
Content-Length: 345
Date: Mon, 05 Mar 2012 07:31:36 GMT
Server: lighttpd

И это то, что я ожидаю увидеть...

2012-03-05 08:42:43: (request.c.294) fd: 6 request-len: 164 
POST /foo1 HTTP/1.1
Host: 192.168.0.1
User-Agent: gSOAP/2.7
Content-Type: text/xml; charset=utf-8
Content-Length: 450
Connection: close
SOAPAction: ""


2012-03-05 08:42:43: (response.c.205) -- splitting Request-URI 
2012-03-05 08:42:43: (response.c.206) Request-URI  :  /foo1 
2012-03-05 08:42:43: (response.c.207) URI-scheme   :  http 
2012-03-05 08:42:43: (response.c.208) URI-authority:  192.168.0.1
2012-03-05 08:42:43: (response.c.209) URI-path     :  /foo1 
2012-03-05 08:42:43: (response.c.210) URI-query    :   
2012-03-05 08:42:43: (response.c.260) -- sanatising URI 
2012-03-05 08:42:43: (response.c.261) URI-path     :  /foo1 
2012-03-05 08:42:43: (mod_proxy.c.1080) proxy - start 
2012-03-05 08:42:43: (mod_proxy.c.1116) proxy - ext found 
2012-03-05 08:42:43: (mod_proxy.c.1159) proxy - used fair balancing 
2012-03-05 08:42:43: (mod_proxy.c.1240) proxy - found a host 127.0.0.1 11111 
2012-03-05 08:42:43: (response.c.375) -- before doc_root 
2012-03-05 08:42:43: (response.c.376) Doc-Root     : /var/www 
2012-03-05 08:42:43: (response.c.377) Rel-Path     : /foo1 
2012-03-05 08:42:43: (response.c.378) Path         :  
2012-03-05 08:42:43: (response.c.426) -- after doc_root 
2012-03-05 08:42:43: (response.c.427) Doc-Root     : /var/www 
2012-03-05 08:42:43: (response.c.428) Rel-Path     : /foo1 
2012-03-05 08:42:43: (response.c.429) Path         : /var/www/foo1 
2012-03-05 08:42:43: (response.c.446) -- logical -> physical 
2012-03-05 08:42:43: (response.c.447) Doc-Root     : /var/www 
2012-03-05 08:42:43: (response.c.448) Rel-Path     : /foo1 
2012-03-05 08:42:43: (response.c.449) Path         : /var/www/foo1 
2012-03-05 08:42:43: (mod_proxy.c.377) connect delayed: 7 
2012-03-05 08:42:43: (mod_proxy.c.994) proxy: fdevent-out 1 
2012-03-05 08:42:43: (mod_proxy.c.805) proxy - connect - delayed success 
2012-03-05 08:42:43: (mod_proxy.c.961) proxy: fdevent-in 4 
2012-03-05 08:42:43: (mod_proxy.c.645) proxy - have to read: 607 
2012-03-05 08:42:43: (mod_proxy.c.961) proxy: fdevent-in 4 
2012-03-05 08:42:43: (mod_proxy.c.645) proxy - have to read: 0 
2012-03-05 08:42:43: (response.c.114) Response-Header: 
HTTP/1.1 200 OK
Connection: close
Server: gSOAP/2.7
Content-Type: text/xml; charset=utf-8
Content-Length: 490
Date: Mon, 05 Mar 2012 07:42:43 GMT

Будет ли новая версия решить эту проблему? Любые другие предложения?

Спасибо заранее!

0

lighttpd mod-proxy

Источник

user696597 05 мар '12 в 15:23

1 ответ

Другие вопросы по тегам lighttpd mod-proxy

user204101 11 мар '12 в 01:30 2012-03-11 01:30 · Answer 1 · 2012-03-11 01:30

mod_proxy в lighttpd имеет много ошибок и не так уж надежен (такие вещи, как большое несоответствие скоростей восходящего и нисходящего потоков, могут отключить его, потому что отсутствует контроль потока). Сказав это, вы должны взглянуть на использование более новой версии lighttpd, чем 1.4.18 - версия 1.4.30 является текущей. Тем не менее, даже обновленная версия может наткнуться на вашу конкретную сеть.

Поскольку вы находитесь во встроенной среде, обновление lighttpd может оказаться невозможным, поэтому вы также можете попробовать некоторые приемы, такие как повторение адреса обратного потока, чтобы mod_proxy "переключался" на тот же сервер, если он считает, что произошла ошибка. Вы также можете играть с proxy.balance конфиг, который принимает значение fair, round-robin или же hash - иногда это может помочь.