Сообщаем о ремонтных работах на сервере

[Gena Makhomed]

на хабре появилась статья http://habrahabr.ru/blogs/webdev/103406/
с описанием недостатков приведенного в документации nginx способа

location / {
     try_files      /system/maintenance.html
                    $uri  $uri/index.html  $uri.html
                    @mongrel;
}

вместо

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

этот фрагмент конфига приводит к тому, что возвращается

HTTP/1.1 200 OK

что создает неприятные побочные эффекты с поисковыми машинами.

это уже вторая проблема с методом try_files /system/maintenance.html
первая обсуждалась в теме "Можно ли боротся с кэшэм страницы-заглушки?"
там была проблема в том, что для этой страницы надо как-то выставить
заголовок "Cache-Control: no-cache", сейчас - проблема в том,
что надо выставить 503 статус и заголовок "Retry-After: 3600".

предлагаемый вариант решения этих и других проблем с файлами-заглушками:

если в директиве try_files указано имя файла, которое не содержит 
переменных - значит это файл-заглушка, и в случае существования
этого файла - искать location = c этим именем файла, и если такой
location обнаружен - сделать в него internal redirect. если такой
location не обнаружен - действовать как и раньше, просто отдать
этот файл с HTTP/1.1 200 OK и дефлтовыми заголовками.

пример конфига:

location / {
     try_files /system/maintenance.html $uri $uri/ @default;
}

location = /system/maintenance.html {
     add_header Cache-Control no-cache;
     add_header Retry-After 3600;
     error_page 503 = /503.html;
     return 503;
     internal;
}

преимущества:

  * полная обратная совместимость с существующими конфигурациями nginx
  * решение всех известных на сегодня проблем со страницами-заглушками
  * сайт может переводиться в/из maintenance mode c помощью touch и rm

P.S. потребуется также внести изменения в ngx_http_headers_module,
чтобы с помощью директивы add_header можно было добавлять заголовки
Cache-Control и Retry-After к ответам с 503 статусом.

-- 
Best regards,
  Gena