web-dev-qa-db-fra.com

Nouvelle tentative d'en-tête de réponse HTTP - cela affecte-t-il quelque chose?

Si je veux refuser poliment le service sur un site Web en raison d'une surcharge temporaire, la réponse HTTP 503 Service Unavailable semble appropriée. La spécification mentionne l'envoi d'un en-tête Retry-after avec le 503.

Y a-t-il un point? La nouvelle tentative affecte-t-elle quelque chose? Les navigateurs y prêtent-ils attention?

httphttp-headers
56
user213154

Pour autant que je sache, aucun navigateur ne fait attention à un Retry-after entête. Les procurations et les caches pourraient, mais

Apparemment, certains navigateurs incluent désormais un certain niveau de support pour Retry-After (bien que le support soit encore au mieux incertain). Je ne suis pas entièrement convaincu de l'intérêt de le faire dans un navigateur; généralement, il est considéré comme une mauvaise idée de mettre en cache les échecs. Mais si vous savez quand vous accepterez à nouveau les demandes, le client ne pourra pas faire de mal. (Si vous revenez plus tôt que prévu, cependant, tout programme qui respecte réellement l'en-tête doit supposer - et signaler - que le site est toujours en panne.)

L'avantage le plus évident est, il semble que Googlebot (et peut-être d'autres araignées) fera attention à l'en-tête s'il est là, ce qui peut l'empêcher de désindexer la page pendant un certain temps.

Cela dit ... si c'est trivial à ajouter et que vous pouvez arriver à une estimation raisonnablement précise de la date à laquelle le service sera disponible, allez-y. Cependant, je ne recommanderais pas de faire de votre mieux pour le faire. Ce n'est qu'un conseil de toute façon, et mettre le mauvais moment là-dedans pourrait causer plus de problèmes que de ne pas inclure l'en-tête du tout.

21
cHao

L'état actuel de l'en-tête Retry-After

L'implémentation de l'en-tête Retry-After dans les clients et les serveurs a quelque peu changé ces dernières années depuis la publication initiale de cette question. J'ai donc pensé fournir une réponse mise à jour.

Tout d'abord, RFC 2616, section 14.37 Réessayer après indique:

Le champ d'en-tête de réponse Réessayer après peut être utilisé avec une réponse 503 (Service non disponible) pour indiquer pendant combien de temps le service ne sera pas disponible pour le client demandeur.

...

Deux exemples de son utilisation sont

  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
  Retry-After: 120

Dans ce dernier exemple, le retard est de 2 minutes.

Prise en charge des logiciels client et serveur

Voici les messages de validation, les annonces et la documentation du référentiel de code concernant l'en-tête Retry-After dans divers logiciels.

Chrome/Chrome

Une validation de code le 22 novembre 2012 avec le message de journal: Ajout de délais d'expiration de détection et utilisation de l'en-tête HTTP Retry-After .

Mozilla/Firefox

Une validation de code le 27 mars 2012 avec le message logeage: Implémenter la gestion de 5xxs, X-Weave-Backoff, Retry-After . De plus, il y a trois autres mentions d'en-tête Retry-After dans leur référentiel Mercurial.

Un bogue a été initialement soumis le 6 janvier 2004 avec le titre Retry-After envoyé avec la réponse HTTP 503 est ignoré .

Googlebot

Un article du blog Google Webmaster Central sur le traitement des temps d'arrêt du site mentionne que l'en-tête Réessayer après peut être utilisé pour déterminer quand ré-analyser l'URL .

Bingbot/Msnbot

Impossible de trouver un document de support officiel pour la nouvelle tentative. Cependant, il y avait quelques mentions dans des forums aléatoires sur l'utilisation de cet en-tête dans une réponse 503 pour étrangler les robots de Microsoft.

Nginx

directive add_header indique:

Ajoute le champ spécifié à un en-tête de réponse à condition que le code de réponse soit égal à 200, 201, 204, 206, 301, 302, 303, 304 ou 307.

Par conséquent, pour ajouter l'en-tête Retry-After pour une réponse 503 à l'aide de la version:

  • 1.7.4 et versions antérieures, utilisez un module tiers, tel que En-têtes Plus .

  • 1.7.5 et versions ultérieures, ajoutez le paramètre always au add_header directive.

Apache

Contrairement à Nginx, Apache documentation d'en-tête ne donne aucune indication qu'il ne peut pas envoyer d'en-tête Retry-After sur une réponse 503. En ce qui concerne les réponses non 2xx, cependant, les documents indiquent:

ajouter un en-tête à une réponse non réussie (non-2xx) générée localement, telle qu'une redirection, auquel cas seule la table correspondant à toujours est utilisée dans la réponse finale.

Voici un réponse SO qui définit un en-tête Retry-After avec la condition toujours pour 503 réponses, comme le doc le conseille.

Un article AskApache fournit d'autres exemples de configuration sur la façon de demander aux moteurs de recherche de revenir en utilisant une réponse 503 avec un en-tête Retry-After.

Test client

J'ai écrit un serveur Ruby qui renvoie simplement une réponse 503 avec un en-tête Retry-After défini sur 10 secondes et un corps contenant un nombre aléatoire.

require 'sinatra'

get '/' do
  headers 'Content-Type' => 'text/plain', 'Retry-After' => '10'
  status 503
  body Rand(1000).to_s
end

Je l'ai accédé sur:

  • OpenBSD 5.8 utilisant Chromium 44, Firefox-ESR 38 et Seamonkey 2.33,
  • Mac OSX 10.7.5 utilisant Chrome 47 et Safari 6.1,
  • Windows 10 utilisant Chrome 48, Firefox 41 et Edge 25.

Je m'attendais à ce que ces navigateurs actualisent automatiquement l'URL après 10 secondes et affichent un nouveau nombre aléatoire. Cependant, tous les navigateurs n'ont pas réessayé, même après plusieurs minutes. J'ai également essayé des périodes de réessai plus courtes et plus longues avec les mêmes résultats. Le journal d'accès au serveur a confirmé qu'aucune nouvelle tentative n'a été effectuée à partir de ces navigateurs.

En outre, une actualisation "douce" avant la période de nouvelle tentative a immédiatement récupéré l'URL. Ainsi, l'en-tête Retry-After ne peut pas être utilisé pour limiter les utilisateurs "heureux de rafraîchissement". Je mentionne cela parce que j'ai vu dans certains forums que cet en-tête pouvait être utilisé pour empêcher les utilisateurs impatients de marteler votre site.

En remarque, il semble logique qu'une actualisation "douce" n'ait aucune action avant la période de temporisation, mais une actualisation "dure" ou de contournement du cache ignorerait toute temporisation et récupérerait immédiatement l'URL.

Conclusion

La prise en charge de l'en-tête Retry-After semble toujours un peu sommaire sur les clients et les serveurs. Néanmoins, c'est une bonne idée de définir un délai de relance pour 503 réponses s'il n'est pas difficile à configurer.

Même si Googlebot est le seul client à prendre en charge l'en-tête et à réessayer après la période d'expiration, il peut empêcher la désindexation de vos pages, par opposition à une réponse 404, 500, 502 ou 504.

77
Clint Pachl

Je vois cela comme un problème de poulet et d'œufs: aucun navigateur n'implémente actuellement Retry-after car aucun site Web ne le dérange. À mon avis, allez-y et envoyez-le en tant que service aux utilisateurs. Si leur choix de navigateur Web ne le met pas en œuvre, c'est que leur navigateur ne leur donne tout simplement pas d'informations utiles. Tu l'as fait!

Lorsque je cherche à implémenter des normes qui ont plusieurs implémentations concurrentes, j'essaie toujours d'adhérer aux normes et de ne pas prêter attention aux différentes implémentations (à moins que j'essaye spécifiquement d'émuler une implémentation, comme cURLing mais déguiser mes en-têtes pour ressembler à un navigateur Web). Sinon, nous nous retrouvons avec des normes de facto, que si vous vous souvenez des jours de domination IE, vous ne voulez pas!

8
dotancohen

Si vous souhaitez envoyer un rafraîchissement automatique après X fois, vous pouvez envoyer un

Refresh: 120; url=http://your_url.com

en PHP:

header("Refresh: "    .$retry_time."; url=". $url);

Pour actualiser la page actuelle, vous pouvez utiliser $_SERVER["REQUEST_URI"] pour $ url.

J'ai testé cet en-tête avec succès dans différentes versions d'Opera, Firefox et Internet Explorer.

Cet en-tête fonctionne même pour actualiser le contenu binaire comme les images (mais uniquement lorsqu'il est chargé directement ou dans un cadre - un IMG-Tag ne se rechargera pas).

1
Radon8472