Если я хочу вежливо отказаться от обслуживания на веб-сайте из-за временной перегрузки, ответ HTTP 503 Service Unavailable представляется подходящим. В спецификации упоминается отправка Retry-after с 503.
Есть ли какая-нибудь точка? Влияет ли Retry-after на что-либо? Броузеры обращают на это внимание?
Насколько я знаю, ни один браузер не обращает внимания на заголовок Retry-after. Прокси и кеши могут, но
По-видимому, некоторые браузеры теперь включают некоторый уровень поддержки Retry-after (хотя поддержка по-прежнему в лучшем случае). Я не совсем убежден в том, что это можно сделать в браузере; в целом, он считал плохую идею кэшировать сбои. Но если вы знаете, когда будете снова принимать запросы, сообщить клиенту, что он не пострадал. (Если вы вернетесь раньше, чем ожидалось, любая программа, которая на самом деле чтит заголовок, должна принять и сообщить, что сайт все еще не работает.)
Наиболее очевидным преимуществом является то, что Googlebot (и, возможно, другие пауки) обратит внимание на заголовок, если он есть, что может помешать ему некорректно индексировать страницу на некоторое время.
Со всем, что было сказано... если это тривиально добавить, и вы можете придумать достаточно точную оценку того, когда услуга будет доступна, идите за ней. Однако я бы не рекомендовал, чтобы вы делали это. В любом случае, это будет только рекомендация, и неправильное время может вызвать больше проблем, чем вообще не включать заголовок.
Реализация заголовка Retry-After на клиентах и серверах несколько изменилась за последние годы после первоначальной публикации этого вопроса. Поэтому я подумал, что дам обновленный ответ.
Прежде всего, RFC 2616, раздел 14.37 Retry-After:
Поле заголовка ответа Retry-After можно использовать с ответом 503 (недоступность службы), чтобы указать, как долго ожидается, что служба будет недоступна запрашивающему клиенту.
...
Два примера его использования:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: 120В последнем примере задержка составляет 2 минуты.
Ниже перечислены сообщения о фиксации репозитория кода, объявления и документация относительно заголовка Retry-After в различных программах.
Код фиксации 22 ноября 2012 года с сообщением журнала: Добавлены тайм-ауты обнаружения и использование HTTP-заголовка Retry-After.
Код фиксации 27 марта 2012 года с журналом messeage: Реализация обработки 5xxs, X-Weave-Backoff, Retry-After. Кроме того, в их хранилище Mercurial есть три других упоминания заголовка Retry-After.
Ошибка была первоначально отправлена 6 января 2004 года с заголовком Retry-After, отправленный с ответом HTTP 503, игнорируется.
Статья в блоге Google Webmaster Central Blog о том, как работать с простоями сайта, означает, что заголовок Retry-After может использоваться для определения того, когда нужно пересканировать URL.
Не удалось найти официальный документ поддержки Retry-After. Однако в случайных форумах было несколько упоминаний об использовании этого заголовка в ответе 503 для дросселирования ботов Microsoft.
директива add_header утверждает:
Добавляет указанное поле в заголовок ответа при условии, что код ответа равен 200, 201, 204, 206, 301, 302, 303, 304 или 307.
Следовательно, чтобы добавить заголовок Retry-After для ответа 503, используя версию:
1.7.4 и ранее, используйте сторонний модуль, например Заголовки больше.
1.7.5 и более поздних версий добавьте параметр always в директиву add_header.
В отличие от Nginx, документация заголовка Apache не указывает, что он не может отправить заголовок Retry-After в ответ 503. Однако в отношении ответов, отличных от 2xx, состояние документов:
добавление заголовка к локально генерируемому отклику неуспеха (не 2xx), например, перенаправление, и в этом случае в конечном ответе используется только таблица, соответствующая всегда.
Вот ответ SO, который устанавливает заголовок Retry-After с условием всегда для 503 ответов, как советует doc.
В статье AskApache содержатся другие примеры конфигурации того, как дать команду поисковым системам вернуться с использованием ответа 503 с заголовком Retry-After.
Я написал сервер Ruby, который просто возвращает ответ 503 с заголовком Retry-After, установленным на 10 секунд, и тело, содержащее случайное число.
require 'sinatra'
get '/' do
headers 'Content-Type' => 'text/plain', 'Retry-After' => '10'
status 503
body rand(1000).to_s
end
Я обратился к нему по адресу:
Я ожидал, что эти браузеры будут автоматически обновлять URL через 10 секунд и отображать новое случайное число. Тем не менее, все браузеры не повторялись, даже через несколько минут. Я пробовал более короткие и длительные периоды Retry-After с такими же результатами. Журнал доступа к серверу подтвердил, что никаких попыток никогда не было сделано ни с одним из этих браузеров.
Кроме того, "мягкое" обновление перед периодом "Повторить-после" мгновенно перенаправляет URL-адрес. Поэтому заголовок Retry-After не может использоваться для дросселирования "обновленных счастливых" пользователей. Я упоминаю об этом, потому что в каком-то форуме я видел, что этот заголовок можно использовать для подавления нетерпеливых пользователей от забивания вашего сайта.
В качестве побочного примечания кажется логичным для "мягкого" обновления не иметь никаких действий до периода ожидания, но "жесткое" или обновление кэша-байпаса будет игнорировать любой тайм-аут и немедленно восстановить URL-адрес.
Поддержка заголовка Retry-After по-прежнему кажется немного отрывочным как на клиентах, так и на серверах. Тем не менее, рекомендуется установить тайм-аут повтора для 503 ответов, если нетрудно настроить.
Даже если робот Googlebot является единственным клиентом, поддерживающим заголовок, и на самом деле повторяет попытку после периода ожидания, он может не деинсталлировать ваши страницы - в отличие от ответа 404, 500, 502 или 504.
Я рассматриваю это как проблему с курицей и яйцом: ни один браузер не реализует Retry-after, поскольку веб-сайты не беспокоятся. По-моему, продолжайте и отправляйте его как услугу пользователям. Если их выбор веб-браузера не реализует его, то это их браузер, просто не предоставляя им полезную информацию. Вы сделали!
При поиске стандартов, которые имеют несколько конкурирующих реализаций, я всегда стараюсь придерживаться стандартов и не обращать внимания на различные реализации (если я специально не пытаюсь подражать реализации, например cURLing, но маскируя свои заголовки выглядят как веб-браузер). В противном случае мы получим стандарты defacto, которые, если вы помните дни IE-доминирования, которые вам не нужны!
Если вы хотите отправить автоматическое обновление после X-времени, вы можете отправить
Refresh: 120; url=http://your_url.com
в PHP:
header("Refresh: " .$retry_time."; url=". $url);
Чтобы обновить текущую страницу, вы можете использовать $_SERVER["REQUEST_URI"] для $url.
Я тестировал этот заголовок успешно в разных версиях Opera, Firefox и Internet Explorer.
Этот заголовок даже работает для обновления двоичного содержимого, такого как изображения (но только тогда, когда загружается напрямую или в кадре - IMG-тег не перезагружается).