Текущее состояние заголовка Retry-After
Реализация заголовка Retry-After на клиентах и серверах несколько изменилась за последние годы с момента первоначальной публикации этого вопроса. Поэтому я решил дать обновленный ответ.
Прежде всего, RFC 2616, раздел 14.37 Повторная попытка состояния:
Поле заголовка ответа Retry-After можно использовать с ответом 503 (Служба недоступна), чтобы указать, как долго ожидается, что служба будет недоступна для запрашивающего клиента.
...
Два примера его использования:
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
В последнем примере задержка составляет 2 минуты.
Поддержка клиентского и серверного программного обеспечения
Ниже приведены сообщения, объявления и документы о фиксации в хранилище кода, касающиеся заголовка Retry-After в различных программах.
хром / хром
Код коммит 22 ноября 2012 г. с сообщением журнала:
Добавлены тайм-ауты обнаружения и использования HTTP-заголовка Retry-After .
Mozilla / Firefox
Фиксация кода 27 марта 2012 г. с сообщением журнала: Реализация обработки 5xxs, X-Weave-Backoff, Retry-After . Кроме того, в их хранилище Mercurial есть три других упоминания заголовка Retry-After .
Ошибка была первоначально отправлена 6 января 2004 года с заголовком Повтор после отправки с HTTP 503, ответ игнорируется .
Googlebot
В статье Центрального блога Google для веб-мастеров, посвященной простоям на сайте, упоминается, что заголовок Retry-After может использоваться для определения, когда нужно пересмотреть URL .
Bingbot / MSNbot
Не удалось найти официальный документ поддержки Retry-After. Тем не менее, было несколько упоминаний на случайных форумах об использовании этого заголовка в ответе 503 на дроссельные роботы Microsoft.
Nginx
Директива add_header гласит:
Добавляет указанное поле к заголовку ответа при условии, что код ответа равен 200, 201, 204, 206, 301, 302, 303, 304 или 307.
Поэтому, чтобы добавить заголовок Retry-After для ответа 503, используя версию:
1.7.4 и более ранние версии, используйте сторонний модуль, например Заголовки Подробнее .
1.7.5 и выше, добавьте параметр always к директиве add_header.
Apache
В отличие от Nginx, в документации заголовка Apache нет указаний на то, что он не может отправить заголовок Retry-After для ответа 503. Однако в отношении ответов, не относящихся к 2xx, документация гласит:
добавление заголовка к локально сгенерированному неуспешному (не 2xx) ответу, такому как перенаправление, в этом случае в окончательном ответе используется только таблица, соответствующая всегда.
Вот ответ SO , который устанавливает заголовок Retry-After с условием всегда для 503 ответов, как советует документ.
Статья 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
Я получил к нему доступ:
- OpenBSD 5.8 с использованием Chromium 44, Firefox-ESR 38 и Seamonkey 2.33,
- Mac OSX 10.7.5 с использованием Chrome 47 и Safari 6.1,
- Windows 10 с использованием Chrome 48, Firefox 41 и Edge 25.
Я ожидал, что эти браузеры автоматически обновят URL-адрес через 10 секунд и отобразят новое случайное число.Тем не менее, все браузеры не повторили попытку даже через несколько минут.Я пробовал все более короткие и более длительные периоды Retry-After с теми же результатами.Журнал доступа к серверу подтвердил, что ни один из этих браузеров не делал повторных попыток.
Кроме того, «мягкое» обновление перед периодом повторных попыток немедленно обновило URL-адрес.Таким образом, заголовок Retry-After не может использоваться для ограничения «счастливых» пользователей.Я упоминаю об этом, потому что на каком-то форуме я увидел, что этот заголовок можно использовать для того, чтобы не дать нетерпеливым пользователям ударить по вашему сайту.
В качестве примечания, логично, что «мягкое» обновление не выполняет никаких действий дотайм-аут, но «жесткое» или обновление с обходом кэша будет игнорировать любой тайм-аут и немедленно перезапускать URL.кажется немного схематичным как на клиентах, так и на серверах.Тем не менее, неплохо установить время ожидания для 503 ответов, если его нетрудно настроить.
Даже если Googlebot - единственный клиент, поддерживающий заголовок и фактически повторяющий попытки после периода ожидания, он может сохранитьВаши страницы не будут проиндексированы - в отличие от ответа 404, 500, 502 или 504.