Qu'est-ce que le code d'état 300 « Multiple Choices » ?
Table des matières
Nous connaissons les codes 301 « redirection permanente » et 302 d’état de réponse HTTP « redirection temporaire », mais avez-vous entendu parler du code d’état 300 ? Ne vous inquiétez pas si ce n’est pas le cas, vous n’êtes pas seul. Ce n’est pas aussi courant que les autres codes d’état de réponse HTTP 3XX.
Le code de statut 300 possède des caractéristiques uniques qui le rendent utile dans certains cas spécifiques.
Dans ce guide, nous explorerons le code d’état 300, ses applications et les problèmes les plus courants qui y sont associés.
Comment fonctionne le code d’état 300 ?
Voici à quoi ressemble une interaction client-serveur typique impliquant un code de réponse 300 :
- Un client demande une ressource : un client (navigateur, application) envoie une requête HTTP (GET, POST, etc.) à un serveur web pour une ressource spécifique.
- Le serveur web traite la demande : le serveur web reçoit la demande et détermine que la ressource a plusieurs versions. Il peut s’agir de pages dans différentes langues, formats (XML, JSON, etc.) ou emplacements.
- Le serveur web répond avec le code de réponse HTTP 300 « Multiple Choices » : le serveur web renvoie le code de réponse 300 au client. Cette réponse contient une liste d’options disponibles parmi lesquelles le client peut choisir.
La liste peut être présentée dans le corps de la demande ou dans l’en-tête « Location ».
- Le client fait un choix et renvoie une nouvelle requête : le client doit choisir l’une des options présentées et renvoyer une autre requête HTTP informant le serveur du choix.
Alternativement, l’application client peut être configurée pour effectuer une sélection automatique basée sur des critères prédéfinis. - Le serveur web traite la requête suivante : le serveur web traite la nouvelle requête. Il répond avec la ressource correspondant au choix effectué par le client. En cas de succès, la nouvelle réponse est 200 « OK ».
Selon le site web auquel la requête HTTP est envoyée, ces choix sont présentés sous la forme d’URI, Alternates ou En-têtes HTTP Link (les méthodes les plus utilisées).
Si l’un des choix est préféré, le serveur web doit générer un en-tête HTTP Location spécifiant l’URI de la version de ressource préférée.
Sauf si la méthode de requête HTTP est HEAD, comme une requête POST ou GET, le code de réponse 300 comporte un corps de message contenant une liste des choix disponibles.
Vous trouverez ci-dessous un exemple d’une telle réponse.
HTTP/1.1 300 Multiple Choices
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<title>300 Multiple Choices</title>
</head>
<body>
<h1>Choix multiples</h1>
<p>La ressource demandée a plusieurs représentations. Veuillez sélectionner l'une des options suivantes :</p>
<ul>
<li><a href="http://example.com/resource/en">Anglais</a></li>
<li><a href="http://example.com/resource/fr">Français</a></li>
<li><a href="http://example.com/resource/es">Espagnol</a></li>
</ul>
</body>
</html>Le code de réponse 300 peut être mis en cache. Cela signifie que les clients (navigateurs ou agents utilisateurs) peuvent enregistrer la réponse et la charger depuis leur stockage pour toute demande future, augmentant ainsi les performances. Le serveur web vérifie la date de dernière modification dans les champs d’en-tête de requête envoyés par un client qui a déjà mis en cache la ressource et, si elle correspond à la dernière version de la ressource, renvoie un 304 « Non modifié » code de réponse.
En général, le code de statut 300 n’est pas largement utilisé car il n’existe pas de manière standardisée de présenter les choix.
Caractéristiques clés de 300 Multiple Choices
Le code de réponse 300 présente plusieurs caractéristiques importantes qui le distinguent des autres codes d’état HTTP.
Options multiples
Le serveur présente plusieurs options parmi lesquelles le client peut choisir. La façon dont ces options sont présentées dépend du serveur ou du site web.
Il peut s’agir d’une liste à puces ou numérotée dans le corps de la réponse 300 ou d’une liste dans l’en-tête « Location ».
Pas de redirection automatique
Contrairement aux autres codes 3xx, 300 ne redirige pas automatiquement l’utilisateur vers un emplacement spécifique. Au lieu de cela, le visiteur doit choisir l’emplacement de la ressource souhaitée.
Le serveur web ne fournira pas de contenu tant que le client n’aura pas explicitement fait un choix. Qu’il s’agisse d’une sélection manuelle ou automatique effectuée par une application dépend entièrement du client.
Interaction utilisateur requise
Avec le code de réponse HTTP 300, le serveur d’origine demande à l’utilisateur (agent utilisateur) de sélectionner l’un des choix disponibles.
Le serveur ne peut pas continuer tant qu’une des options n’est pas sélectionnée.
Quand 300 Multiple Choices sont-ils utilisés ?
Bien que rarement utilisé, le code de statut 300 possède des caractéristiques distinctes qui le rendent utile dans des cas spécifiques. Voici les plus courants.
Négocier plusieurs formats
Lorsqu’une ressource est disponible dans plusieurs formats (par exemple, différentes langues et types de médias), le serveur d’origine permet aux utilisateurs de choisir leurs préférences en utilisant un code de réponse 300.
Par exemple, vous pouvez répertorier plusieurs formats optionnels (MPEG, MP4, etc.) pour la même vidéo parmi lesquels les clients peuvent choisir.
Sélection des versions de ressources
Si une ressource possède plusieurs versions, telles que des versions d’API, le code d’état 300 indique les options disponibles aux utilisateurs.
Par exemple, un serveur peut proposer un document dans différentes langues ou formats, tels que HTML, PDF ou texte brut. Le client peut ensuite sélectionner la version souhaitée en fonction des préférences ou des capacités de l’utilisateur. Ce mécanisme permet une diffusion de contenu plus flexible, garantissant que le client reçoit la ressource la plus appropriée sans faire plusieurs demandes ultérieures.
Ressources alternatives
Lorsqu’une ressource dispose de plusieurs emplacements ou représentations alternatives, le serveur peut proposer ces choix au client.
Supposons que vous souhaitiez afficher un contenu différent pour différentes régions. Avant de continuer sur votre site Web, vous pouvez inviter les visiteurs à sélectionner leur région dans un menu avec un code de réponse 300.
Conseils pour gérer un code de statut 300
Le code de réponse 300 n’est pas aussi populaire que les autres types de redirection, les utilisateurs ne le connaissent donc pas très bien. Par conséquent, vous devez être très prudent et diligent lorsque vous l’utilisez pour vous assurer que le code d’état HTTP 300 ne les confond pas.
Vous trouverez ci-dessous quelques conseils utiles pour gérer un code de réponse de 300 « Multiple Choices ».
- Maintenir une documentation claire – Documenter les différents choix disponibles et les critères pour chacun. Cela aidera les développeurs et les utilisateurs à mieux comprendre les options lorsqu’ils rencontreront le code HTTP 300.
- Conserver la cohérence des noms : utilisez une convention de dénomination cohérente pour les différentes versions de ressources. Cela aidera les utilisateurs à savoir clairement ce qu’ils choisissent.
- Traitement côté client – Assurez-vous que les applications clientes, telles que les navigateurs ou les applications mobiles, peuvent gérer correctement 300 réponses.
- Mises à jour régulières – Gardez à jour la liste des choix disponibles. Si une représentation ou une version d’une ressource devient obsolète, supprimez-la des options pour éviter les liens rompus.
- Fournir des instructions claires – Créez une interface intuitive et conviviale pour votre site web ou votre application web. Inclure un texte descriptif et des instructions claires pour chaque choix.
De cette façon, vous éviterez de frustrer vos visiteurs, qui comprendront clairement les choix présentés. De plus, des instructions claires aideront les moteurs de recherche à explorer correctement votre site. - Effectuer des tests multi-appareils/navigateurs – La compatibilité multi-appareils/plateformes est essentielle de nos jours. Testez régulièrement votre site web ou votre application sur différents appareils ou navigateurs pour vous assurer qu’ils peuvent gérer correctement les choix proposés dans le code de réponse 300.
- Surveiller l’utilisation – Gardez une trace de la fréquence à laquelle chaque option est sélectionnée. Vous pouvez utiliser ces informations pour définir un emplacement de ressource par défaut qui répond aux préférences de vos utilisateurs.
Vous pouvez utiliser divers outils pour surveiller quelles pages génèrent le plus de trafic. De nombreux fournisseurs d’hébergement web proposent des outils internes d’analyse du trafic qui répartissent le trafic par page consultée. Les utilisateurs de SiteGround peuvent surveiller leur trafic depuis Site Tools > Statistiques > Trafic.
Si votre hébergement web ne fournit pas de tels instruments, vous pouvez opter pour des services de surveillance tiers. (comme Google Analytics ou Ahrefs) ou des plugins (pour WordPress, Joomla, etc. ).
Problèmes courants
Comme tout autre type de redirection, le code d’état 300 peut avoir des ratés s’il n’est pas utilisé correctement. Cela peut amener un site web à produire une réponse invalide affichant un code d’erreur ou une page vierge. Voici quelques-unes des causes d’un code de réponse 300 problématique.
Options mal configurées
Une configuration incorrecte des choix disponibles présentés par un code HTTP 300 peut dérouter les utilisateurs et entraîner des erreurs. De telles erreurs de configuration pourraient être :
- Liens brisés : les URL incomplètes n’ouvriront pas la page désignée et confondront les visiteurs, ce qui entraînera une détérioration de l’expérience utilisateur.
- Type de contenu incorrect : Content-Type est un en-tête de représentation conçu pour informer les clients du type de média de la ressource demandée. Si l’en-tête Content-Type ne correspond pas au type réel d’une ressource, la requête client suivante risque de ne pas exécuter correctement la ressource cible.
- Aucun mécanisme de secours : le code de réponse 300 n’inclut pas d’option par défaut ni de mécanisme de secours au cas où l’utilisateur ne pourrait pas faire de choix ou si le client ne prend pas en charge les codes de réponse 300.
Nomination incohérente des choix
Les liens qui ne suivent pas une convention de dénomination cohérente rendent les choix peu clairs. Par exemple, un lien peut être nommé « ressource/en » à un endroit et « ressource /anglais” dans un autre.
En conséquence, les visiteurs sont plus susceptibles de quitter votre site web au lieu de donner suite à leurs choix.
Guide utilisateur peu clair
Des descriptions ou instructions peu claires peuvent dérouter les clients quant aux choix proposés. En outre, ils peuvent empêcher les moteurs de recherche d’explorer correctement votre site web. Ainsi, l’expérience utilisateur et le score SEO peuvent en souffrir.
Incompatibilité des navigateurs
Certains navigateurs peuvent ne pas gérer correctement 300 réponses, ce qui entraîne un dysfonctionnement du site web ou de l’application avec lequel ils communiquent. Par exemple, de telles incompatibilités peuvent survenir lorsque l’entité de requête contient un champ d’en-tête de requête Expect, qui spécifie la réponse attendue par le client.
Si le code d’état 300 n’est pas une réponse demandée, le client risque de ne pas être en mesure de le traiter correctement.
Comment résoudre les problèmes de code HTTP 300 mal configuré ?
Vérifier la configuration du serveur
Assurez-vous que votre serveur web spécifie correctement les choix multiples présentés dans le code de réponse 300. Chaque option doit être une URL valide pointant vers une version différente de la ressource ciblée.
Valider les 300 en-têtes de code de réponse
Examinez les champs d’en-tête de réponse HTTP, tels que l’en-tête Location. Il doit contenir les URL correctes pour les choix disponibles. Des en-têtes incorrects peuvent entraîner des liens rompus et la frustration des utilisateurs.
Inspecter les journaux d’erreurs
Activez la journalisation des erreurs sur votre site web pour inspecter les problèmes enregistrés lorsque les visiteurs accèdent à votre site web. Ces journaux peuvent vous aider à identifier l’origine de nombreuses erreurs côté client (comme le cadrage des messages de requêtes non valides, trop de requêtes, etc.) ou côté serveur (comme des ressources serveur insuffisantes, des restrictions d’accès, etc.).
Ces journaux peuvent également vous aider à identifier les problèmes liés au code de réponse 300. Les utilisateurs de SiteGround disposent de fonctionnalités faciles à trouver et à utiliser. des journaux d’erreurs détaillés à leur disposition dans les Site Tools > Statistiques > Journal des erreurs.
Mettre en œuvre un mécanisme de secours
Si les clients ne peuvent pas gérer le code d’état 300, implémentez un mécanisme de secours qui redirige vers un choix par défaut. Cela garantit que les utilisateurs peuvent toujours accéder à la ressource même s’ils ne font pas de sélection.
Conclusion
Le code d’état 300 est une réponse du serveur invitant les clients à sélectionner parmi plusieurs options pour continuer. Cela peut être très utile, surtout lorsque vous disposez de plusieurs versions d’une ressource (page, formats de fichiers) parmi lesquelles les clients peuvent choisir.
Cependant, il présente également certaines limites, ce qui le rend inadapté à certains scénarios. Si vous décidez de l’intégrer à votre site web ou à votre application, vous devez considérer ses avantages et ses inconvénients. Nous espérons que vous prendrez une décision éclairée après avoir lu cet article.