Résolution des problèmes liés aux points de terminaison Azure Content Delivery Network qui retournent un code d’état 404

Important

Azure CDN Standard de Microsoft (classique) sera mis hors service le 30 septembre 2027. Pour éviter toute interruption de service, il est important de migrer vos profils du niveau Azure CDN Standard de Microsoft (classique) vers le niveau Azure Front Door Standard ou Premium au plus tard le 30 septembre 2027. Pour découvrir plus d’informations, consultez Mise hors service d’Azure CDN Standard de Microsoft (classique).

Azure CDN d’Edgio sera mis hors service le 15 janvier 2025. Pour éviter toute interruption de service, vous devez migrer votre charge de travail vers Azure Front Door avant cette date. Pour plus d’informations, consultez FAQ sur la mise hors service d’Azure CDN d’Edgio.

Cet article vous permet de résoudre les problèmes liés aux points de terminaison Azure Content Delivery Network qui retournent des codes d’état HTTP 404.

Si vous avez besoin d'aide supplémentaire concernant n'importe quel point de cet article, contactez les experts Azure sur les forums MSDN Azure et Stack Overflow. Vous pouvez également signaler un incident au Support Azure. Accédez au site du support Azure, puis sélectionnez Obtenir un support.

Symptôme

Vous avez créé un profil et un point de terminaison de réseau de distribution de contenu, mais votre contenu ne semble pas être disponible sur le réseau de distribution de contenu. Les utilisateurs qui tentent d’accéder à votre contenu via l’URL du réseau de distribution de contenu reçoivent un code d’état HTTP 404.

Cause

Il existe plusieurs causes possibles, y compris :

• L’origine du fichier n’est pas visible par le réseau de distribution de contenu.
• Le point de terminaison est mal configuré et le réseau de distribution de contenu effectue donc la recherche au mauvais endroit.
• L’hôte rejette l’en-tête de l’hôte du réseau de distribution de contenu.
• Le point de terminaison n’a pas eu le temps de se propager dans le réseau de distribution de contenu.

Étapes de dépannage

Important

Lorsqu’un point de terminaison de réseau de distribution de contenu est créé, il n’est pas disponible immédiatement, car la propagation de l’enregistrement dans le réseau de distribution de contenu peut prendre du temps :

• Pour les profils CDN Azure Standard fourni par Microsoft, la propagation s’effectue généralement dans un délai de dix minutes.
• Pour les profils Azure CDN Standard fourni par Edgio et Azure CDN Premium fourni par Edgio, la propagation se termine généralement en 90 minutes.

Si vous suivez les étapes de ce document et que vous obtenez toujours des réponses 404, patientez quelques heures, puis vérifiez à nouveau avant d’ouvrir un ticket de support.

Vérifier le fichier d’origine

Tout d’abord, vérifiez que le fichier à mettre en cache est disponible sur le serveur d’origine et qu’il est accessible publiquement sur Internet. Pour cela, le moyen le plus rapide consiste à ouvrir une session de navigateur en mode privé ou incognito, et d’accéder directement au fichier. Entrez ou collez l’URL dans la zone d’adresse, puis vérifiez que vous accédez bien au fichier attendu. Par exemple, supposons que vous disposez d’un fichier dans un compte de Stockage Azure, accessible à l’adresse HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt. Si vous pouvez charger le contenu de ce fichier, le test est réussi.

Avertissement

Même s’il s’agit du moyen le plus rapide et le plus simple de vérifier que votre fichier est disponible publiquement, certaines configurations réseau de votre organisation peuvent donner l’impression qu’un fichier est accessible publiquement, alors qu’il n’est visible que pour les utilisateurs de votre réseau (même s’il est hébergé dans Azure). Pour vérifier que ce n’est pas le cas, testez le fichier avec un navigateur externe, par exemple avec un appareil mobile qui n’est pas connecté au réseau de votre organisation ou une machine virtuelle dans Azure.

Vérifier les paramètres d’origine

Maintenant que vous avez vérifié la disponibilité publique du fichier sur Internet, vérifiez les paramètres d’origine. Dans le Portail Azure, accédez à votre profil de réseau de distribution de contenu et sélectionnez le point de terminaison que vous dépannez. Dans la page Point de terminaison qui apparaît, sélectionnez l’origine.

La page Origine s’affiche.

Type et nom d’hôte de l’origine

Vérifiez que les valeurs du type d’origine et du nom d’hôte d’origine sont correctes. Dans cet exemple, HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, la partie de nom d’hôte de l’URL est cdndocdemo.blob.core.windows.net, qui est correcte. Étant donné que les origines de Stockage Azure, Web App et Service Cloud utilisent une valeur de la liste déroulante pour le champ Nom d’hôte de l’origine, les erreurs orthographiques ne sont pas un problème. Toutefois, si vous utilisez une origine personnalisée, assurez-vous que le nom d’hôte est correctement orthographié.

Ports HTTP et HTTPS

Vérifiez vos ports HTTP et HTTPS. Dans la plupart des cas, les ports 80 et 443 sont corrects, et aucun changement n’est nécessaire. Toutefois, si le serveur d’origine écoute sur un port différent, cela doit être représenté ici. En cas de doute, affichez l’URL de votre fichier d’origine. Les spécifications HTTP et HTTPS utilisent les ports 80 et 443 par défaut. Dans notre exemple d’URL HTTPS://cdndocdemo.blob.core.windows.net/publicblob/lorem.txt, aucun port n’est spécifié. Par conséquent, le port 443 est défini par défaut, et les paramètres sont corrects.

Cependant, supposons que l’URL du fichier d’origine que vous avez testé précédemment est HTTP://www.contoso.com:8080/file.txt. Notez la partie :8080 qui termine le segment du nom d’hôte. Ce nombre indique au navigateur d’utiliser le port 8080 pour se connecter au serveur web sur www.contoso.com. Vous devez donc entrer 8080 dans le champ Port HTTP. Il est important de noter que ces paramètres de port affectent uniquement le port utilisé par le point de terminaison pour récupérer des informations à partir de l’origine.

Vérifier les paramètres de point de terminaison

Dans la page Point de terminaison, sélectionnez le bouton Configurer.

La page Configurer du point de terminaison de réseau de distribution de contenu s’affiche.

Protocoles

Sous Protocoles, vérifiez que le protocole utilisé par les clients est sélectionné. Étant donné que le protocole utilisé par le client est celui utilisé pour accéder à l’origine, il est important que les ports d’origine soient correctement configurés dans la section précédente. Le point de terminaison de réseau de distribution de contenu écoute uniquement les ports HTTP et HTTPS par défaut (80 et 443), quels que soient les ports d’origine.

Revenons à notre exemple hypothétique avec HTTP://www.contoso.com:8080/file.txt. Vous savez que Contoso a spécifié 8080 comme port HTTP, mais supposons qu’ils ont aussi spécifié 44300 comme port HTTPS. S’il avait créé un point de terminaison nommé contoso, le nom d’hôte du point de terminaison de son réseau de distribution de contenu serait contoso.azureedge.net. Une demande pour HTTP://Contoso.azureedge.net/file.txt étant une requête HTTP, le point de terminaison utiliserait le protocole HTTP sur le port 8080 pour le récupérer à partir de l’origine. Avec une requête sécurisée sur HTTPS, HTTPS://Contoso.azureedge.net/file.txt, le point de terminaison utiliserait le protocole HTTPS sur le port 44300 lors de la récupération du fichier à partir de l’origine.

En-tête de l’hôte d’origine

Le champ En-tête de l’hôte d’origine indique la valeur d’en-tête d’hôte envoyée à l’origine avec chaque demande. Dans la plupart des cas, cette valeur doit être identique au Nom d’hôte d’origine que nous avons vérifié précédemment. Une valeur incorrecte dans ce champ ne provoque pas d’état 404, mais peut provoquer d’autres états 4xx, selon ce qui est attendu par l’origine.

Chemin d’accès d’origine

Enfin, nous devons vérifier le champ Chemin d’accès d’origine, Par défaut, ce chemin est vide. Vous devez l’utiliser uniquement si vous souhaitez limiter les ressources hébergées par l’origine, que vous souhaitez rendre disponibles sur le réseau de distribution de contenu.

Dans cet exemple de point de terminaison, nous voulions que toutes les ressources du compte de stockage soient disponibles. Nous avons donc laissé le champ Chemin d’accès d’origine vide. Par conséquent, une demande envoyée à HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt entraîne une connexion entre le point de terminaison et cdndocdemo.core.windows.net qui demande /publicblob/lorem.txt. De même, avec une requête pour HTTPS://cdndocdemo.azureedge.net/donotcache/status.png, le point de terminaison demande /donotcache/status.png à l’origine.

Mais que se passe-t-il si vous ne souhaitez pas utiliser le réseau de distribution de contenu pour chaque chemin d’accès à votre origine ? Supposons que vous voulez uniquement exposer le chemin du blob public. Si nous entrons /publicblob dans le champ Chemin de l’origine, le point de terminaison insère /publicblob avant chaque demande adressée à l’origine. La demande pour HTTPS://cdndocdemo.azureedge.net/publicblob/lorem.txt prend donc maintenant la partie de demande de l’URL, /publicblob/lorem.txt, et ajoute /publicblob au début. Cela aboutit à une demande de /publicblob/publicblob/lorem.txt à partir de l’origine. Si ce chemin ne se résout pas en fichier réel, l’origine retourne un état 404. L’URL correcte pour récupérer lorem.txt dans cet exemple serait en fait HTTPS://cdndocdemo.azureedge.net/lorem.txt. Nous n’ajoutons pas du tout le chemin /publicblob, car la partie de demande de l’URL est /lorem.txt et le point de terminaison ajoute /publicblob. Par conséquent, la demande passée à l’origine est /publicblob/lorem.txt.