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

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

0 голосов
/ 05 марта 2012

Я использую 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

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

Большое спасибо заранее!

1 Ответ

0 голосов
/ 11 марта 2012

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

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

...