300 Multiple Choices : le code que vous ne verrez presque jamais

Ce pour quoi le code a été conçu

HTTP prend en charge la négociation de contenu : la même URL peut avoir plusieurs représentations qui diffèrent par le format, la langue ou l'encodage. Normalement, le serveur décide, en utilisant les en-têtes Accept, Accept-Language et Accept-Encoding du client, et renvoie celle choisie avec un 200. C'est la négociation pilotée par le serveur, et c'est ce que fait le web.

300 Multiple Choices couvre l'autre approche, la négociation pilotée par l'agent. Plutôt que de choisir, le serveur répond avec une liste des représentations disponibles et laisse le client ou l'utilisateur choisir. La réponse peut inclure un en-tête Location nommant l'option préférée du serveur, que le client est libre de suivre.

Pourquoi vous n'en voyez presque jamais

Le standard n'a jamais spécifié de format lisible par machine pour la liste des choix. Sans format convenu, il n'y a rien qu'un navigateur puisse analyser, donc aucun navigateur grand public n'implémente d'interface de sélection pour un 300. Les navigateurs affichent généralement le corps de la réponse comme une page ordinaire à la place, ou suivent l'en-tête Location s'il est présent, ce qui fait se comporter le 300 comme une redirection faible. Les frameworks d'application et les CDN ne l'émettent pas dans leurs configurations par défaut, et la négociation pilotée par le serveur résout le même problème de façon invisible et meilleure, donc personne n'a de raison de changer.

Un 300 apparaît quand même à quelques endroits :

• Le mod_negotiation d'Apache avec MultiViews activé, quand plusieurs fichiers correspondent à une requête comme /logo et que le module ne peut pas les classer. Il génère une liste HTML de candidats.
• Des API écrites à la main qui renvoient délibérément une liste JSON d'URL de ressources alternatives, utilisant 300 comme indice sémantique plutôt qu'en s'attendant à ce qu'un client la gère nativement.
• Des suites de tests et des outils de conformité au protocole qui exercent chaque code de statut défini.

Pourquoi les gens recherchent le code de statut 300

La plupart des recherches pour « 300 status code » ne portent pas du tout sur un 300. Le chiffre est le début de la famille des redirections, donc les gens qui ont vu une redirection dans un outil de navigateur, un journal ou un robot d'exploration SEO, et qui se sont souvenus « un 3-cent-quelque-chose », recherchent d'abord 300. Ce qu'ils ont généralement est :

• Un 301, une redirection permanente, signalé par un robot d'exploration SEO dans le cadre d'une chaîne.
• Un 302, une redirection temporaire, celle que beaucoup de frameworks émettent par défaut.
• Un 304, qui est une réponse de validation de cache plutôt qu'une redirection.
• Un résumé de robot d'exploration qui regroupe tout sous un en-tête « 3xx », ensuite lu comme « 300 ».

Si vous essayez de déterminer quelle redirection une URL renvoie, le guide 301 vs 302 est celui qu'il vous faut.

Comment vérifier si vous avez vraiment un 300

1. Demandez les en-têtes sans suivre de redirection et lisez le chiffre exact :

   curl -sI https://example.com/some-path | grep -Ei "^(HTTP|location|link|alternates)"

   Un vrai 300 montre HTTP/1.1 300 Multiple Choices. Tout le reste est un code différent et un guide différent.
2. Si c'est vraiment un 300 et que vous ne l'aviez pas prévu, regardez d'abord du côté d'Apache. Désactiver MultiViews pour ce répertoire, ou donner au fichier une extension explicite dans l'URL, retire l'ambiguïté qui déclenche la négociation.
3. Si vous voulez que le serveur choisisse, gardez la négociation pilotée par le serveur : renvoyez 200 avec la représentation sélectionnée et un en-tête Vary nommant les en-têtes de requête sur lesquels vous avez négocié, de sorte que les caches stockent les variantes séparément.
4. Si vous voulez envoyer les clients ailleurs, utilisez une vraie redirection. Les déplacements permanents obtiennent 301 ou 308, les temporaires 302 ou 307. N'utilisez pas 300 comme redirection, car les clients ne sont pas tenus de la suivre.
5. Corrigez l'ambiguïté à la source. Un 300 signifie presque toujours que deux fichiers ou deux routes se disputent la même URL, et la correction durable est de rendre l'URL sans ambiguïté.

Repérer un 300 inattendu après un déploiement

Un 300 inattendu arrive généralement avec une mise à jour de serveur ou un changement de configuration, et personne ne le remarque : la page peut encore paraître à peu près correcte dans un navigateur tandis que les robots d'exploration et les clients d'API reçoivent une réponse qu'ils ne peuvent pas utiliser. Une vérification externe qui enregistre le code de statut exact pour chaque URL fait apparaître le changement dès la première exécution après le déploiement. HostTracker surveille des sites web depuis 2004 et exécute des vérifications depuis plus de 300 points de contrôle répartis dans 158 villes. Vérifiez ce qu'une URL renvoie à l'instant avec l'outil de vérification HTTP, ou lisez le guide complet de la famille des redirections 3xx.