на хабре появилась статья 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


_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru