lighttpd: странное поведение при совпадении нескольких правил перезаписи

у меня есть 20-rewrite.conf для моего приложения php, выглядящего так:

$HTTP["host"] =~ "www.mydomain.com" {
    url.rewrite-once += (
        "^/(img|css)/.*" => "$0",
        ".*" => "/my_app.php"
    )
}

Я хочу иметь возможность перевести веб-сервер в своего рода режим «обслуживания», пока я обновляю свое приложение из scm. Для этого я решил включить дополнительный файл конфигурации перезаписи перед этим. В 16-rewrite-maintenance.conf файл выглядит так:

url.rewrite-once += (
    "^/(img|css)/.*" => "$0",
    ".*" => "/maintenance_app.php"
)

Теперь на странице обслуживания у меня есть логотип, который не загружается. Я получаю ошибку 404. Отладка Lighttpd говорит следующее:

2012-12-13 20:28:06: (response.c.300) -- splitting Request-URI 
2012-12-13 20:28:06: (response.c.301) Request-URI  :  /img/content/logo.png 
2012-12-13 20:28:06: (response.c.302) URI-scheme   :  http 
2012-12-13 20:28:06: (response.c.303) URI-authority:  localhost 
2012-12-13 20:28:06: (response.c.304) URI-path     :  /img/content/logo.png 
2012-12-13 20:28:06: (response.c.305) URI-query    :   
2012-12-13 20:28:06: (response.c.300) -- splitting Request-URI 
2012-12-13 20:28:06: (response.c.301) Request-URI  :  /img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.302) URI-scheme   :  http 
2012-12-13 20:28:06: (response.c.303) URI-authority:  localhost 
2012-12-13 20:28:06: (response.c.304) URI-path     :  /img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.305) URI-query    :   
2012-12-13 20:28:06: (response.c.349) -- sanatising URI 
2012-12-13 20:28:06: (response.c.350) URI-path     :  /img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (mod_access.c.135) -- mod_access_uri_handler called 
2012-12-13 20:28:06: (response.c.470) -- before doc_root 
2012-12-13 20:28:06: (response.c.471) Doc-Root     : /www
2012-12-13 20:28:06: (response.c.472) Rel-Path     : /img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.473) Path         :  
2012-12-13 20:28:06: (response.c.521) -- after doc_root 
2012-12-13 20:28:06: (response.c.522) Doc-Root     : /www 
2012-12-13 20:28:06: (response.c.523) Rel-Path     : /img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.524) Path         : /www/img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.541) -- logical -> physical 
2012-12-13 20:28:06: (response.c.542) Doc-Root     : /www
2012-12-13 20:28:06: (response.c.543) Rel-Path     : /img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.544) Path         : /www/img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.561) -- handling physical path 
2012-12-13 20:28:06: (response.c.562) Path         : /www/img/content/logo.png, /img/content/logo.png 
2012-12-13 20:28:06: (response.c.618) -- file not found 
2012-12-13 20:28:06: (response.c.619) Path         : /www/img/content/logo.png, /img/content/logo.png

Любая подсказка о том, почему lighttpd соответствует обоим правилам (из моей конфигурации перезаписи приложения и из моей конфигурации перезаписи обслуживания) и объединяет их запятой - это, похоже, не имеет никакого смысла ?! Разве это не должно прекратиться после первого совпадения с однократной перезаписью?

url.rewrite является ассоциативным массивом (хеш, dict, что угодно). «Добавление» другого массива с повторяющимися ключами означает, что значения будут объединены запятой (как если бы вы объединяли повторяющиеся заголовки http).

lighttpd -p -f /etc/lighttpd/lighttpd.conf

- хороший способ узнать, как lighttpd видит вашу конфигурацию.

редактировать:

Чтобы включить правила обслуживания, я бы добавил условный блок в конец конфига (побеждает последний активный блок)

$HTTP["host"] =~ "www.mydomain.com" {
    url.rewrite-once = (
        "^/(img|css)/.*" => "$0",
        ".*" => "/maintenance_app.php"
    )
}