Partager via

Codes de réponse HTTP dans Application Gateway

Cet article explique pourquoi Azure Application Gateway retourne des codes de réponse HTTP spécifiques. Les causes courantes et les étapes de résolution de problèmes sont fournies pour vous aider à déterminer la cause racine des codes d’erreur de réponse HTTP. Des codes de réponse HTTP peuvent être renvoyés à une demande de client indépendamment du fait que la connexion ait été lancée vers une cible de back-end ou pas.

Codes de réponse 3XX (redirection)

Les réponses 300-399 sont présentées quand une demande de client correspond à une règle de passerelle applicative qui a des redirections configurées. Les redirections peuvent être configurées sur une règle en l’état ou via une règle de mappage de chemin. Pour plus d’informations sur les redirections, consultez Vue d’ensemble de la redirection Application Gateway.

301 Redirection permanente

Les réponses HTTP 301 sont présentées quand une règle de redirection est spécifiée avec la valeur Permanent.

302 Trouvé.

Les réponses HTTP 302 sont présentées quand une règle de redirection est spécifiée avec la valeur Trouvé.

303 Voir autres

Les réponses HTTP 303 sont présentées quand une règle de redirection est spécifiée avec la valeur Voir autres.

307 Redirection temporaire

Les réponses HTTP 307 sont présentées quand une règle de redirection est spécifiée avec la valeur Temporaire.

Codes de réponse 4XX (erreur du client)

Les codes de réponse 400-499 indiquent un problème initié à partir du client. Ces problèmes peuvent aller du client initiant des requêtes vers un nom d’hôte non correspondant, à l'expiration de la requête, à une demande non authentifiée, à une demande malveillante, etc.

Application Gateway collecte des métriques qui capturent la distribution des codes d’état 4xx/5xx, et a un mécanisme de journalisation qui capture des informations telles que l’adresse IP du client URI avec le code de réponse. Les métriques et la journalisation permettent d’effectuer une résolution des problèmes supplémentaire. Les clients peuvent également recevoir une réponse 4xx d’autres proxys entre l’appareil client et Application Gateway, Par exemple, CDN (Content Delivery Network) et d’autres fournisseurs d’authentification. Consultez les articles suivants pour plus d’informations.

Métriques prises en charge par la référence SKU Application Gateway V2Journaux de diagnostic

400 Demande incorrecte.

Les codes de réponse HTTP 400 sont couramment observés quand :

  • Du trafic non-HTTP/HTTPS est envoyé à une passerelle applicative avec un écouteur HTTP ou HTTPS.
  • Du trafic HTTP est envoyé à un écouteur avec HTTPS, sans redirection configurée.
  • L’authentification mutuelle est configurée et ne peut pas négocier correctement.
  • La requête n’est pas conforme à la RFC.

Voici quelques raisons courantes pour lesquelles la requête peut ne pas être conforme à la RFC :

Catégorie Exemples
Hôte non valide dans la ligne de requête Hôte contenant deux signes deux-points (example.com:8090:8080)
En-tête de l’hôte manquant La requête n’a pas d’en-tête de l’hôte
Présence d’un caractère malformé ou illégal Les caractères réservés sont &,!. La solution de contournement consiste à le coder sous forme de pourcentage. Par exemple : %&
Version HTTP non valide Obtenir /content.css HTTP/0.3
Le nom du champ d’en-tête et l’URI contiennent un caractère non ASCII GET /«úü> ».doc HTTP/1.1
En-tête Content-Length manquant pour une requête POST Explicite
Méthode HTTP non valide GET123 /index.html HTTP/1.1
En-têtes dupliqués Autorisation : <contenu encodé en base64>, Autorisation : <contenu encodé en base64>
Valeur non valide dans Content-Length Content-Length : abc, Content-Length : -10

Dans les cas où l’authentification mutuelle est configurée, plusieurs scénarios peuvent conduire à une réponse HTTP 400 du client, par exemple :

  • L’authentification mutuelle est activée, mais le certificat client n’a pas été présenté.
  • La validation DN (nom unique) est activée et le nom de domaine du certificat client ne correspond pas au nom de domaine de la chaîne de certificats spécifiée.
  • La chaîne du certificat client ne correspond pas à la chaîne de certificat configurée dans la stratégie SSL définie.
  • Le certificat client a expiré.
  • La vérification de révocation du client OCSP (Online Certificate Status Protocol) est activée et le certificat est révoqué.
  • La vérification de révocation du client OCSP (Online Certificate Status Protocol) est activée, mais elle ne peut pas être contactée.
  • La vérification de révocation du client OCSP (Online Certificate Status Protocol) est activée, mais le répondeur OCSP n’est pas fourni dans le certificat.

Pour plus d’informations sur la résolution des problèmes d’authentification mutuelle, consultez Résolution des codes d’erreur.

401 - Non autorisé

Une réponse HTTP 401 Non autorisé est retournée au client si celui-ci n’est pas autorisé à accéder à la ressource. Le code 401 peut être retourné pour plusieurs raisons. En voici quelques-unes, avec des correctifs potentiels.

  • Si le client a accès, il peut avoir un cache de navigateur obsolète. Effacez le cache du navigateur et essayez d’accéder à l’application à nouveau.

Une réponse HTTP 401 Non autorisé peut être retournée pour une requête de sonde AppGW si le pool de back-ends est configuré avec l’authentification NTLM. Dans ce scénario, le backend est marqué comme étant sain. Il existe plusieurs manières de résoudre ce problème :

  • Autorisez l’accès anonyme sur le pool backend.
  • Configurez la sonde pour envoyer la demande vers un autre site « faux » qui n’exige pas d’authentification NTLM.
  • Non recommandé, car cela ne nous indiquera pas si le site réel derrière la passerelle Application Gateway est actif ou non.
  • Configurez la passerelle applicative de façon à autoriser les réponses 401 comme valides pour les sondes : Conditions de mise en correspondance de sondes.

403 - Interdit

HTTP 403 Interdit est présenté quand les clients utilisent des références SKU WAF (pare-feu d'applications web) et que WAF est configuré en mode Prévention. Si des ensembles de règles WAF activés ou des règles WAF de refus personnalisées correspondent aux caractéristiques d’une requête entrante, le client reçoit une réponse 403 Interdit.

Voici d’autres raisons pour lesquelles les clients peuvent recevoir des réponses 403 :

  • Vous utilisez App Service comme back-end et il est configuré de façon à autoriser l’accès uniquement à partir d’Application Gateway. Cela peut conduire App Services à retourner une erreur 403. Cela se produit généralement lorsque des liens de redirection/href pointent directement vers App Services au lieu de pointer vers l’adresse IP d’Application Gateway.
  • Si vous accédez à un blog de stockage et à Application Gateway et que le point de terminaison de stockage se trouve dans une autre région, une erreur 403 est retournée si l’adresse IP publique d’Application Gateway n’est pas autorisée. Consultez Accorder l’accès à partir d’une plage d’adresses IP Internet.

404 - Page introuvable

Une réponse HTTP 404 est générée lorsqu’une requête est envoyée à Application Gateway (références SKU V2) avec un nom d’hôte qui ne correspond à aucun des écouteurs multis sites configurés et qu’aucun écouteur de base n’est présent. En savoir plus sur les types d’écouteurs.

408 – Délai d’attente de la requête dépassé

Une réponse HTTP 408 peut être observée quand les requêtes du client envoyées à l’écouteur front-end de la passerelle applicative ne répondent pas dans les 60 secondes. Cette erreur peut être observée en cas de congestion du trafic entre les réseaux locaux et Azure, quand une appliance virtuelle inspecte le trafic, ou quand le client lui-même est submergé.

413 Entité de requête trop grande

Une réponse HTTP 413 peut être observée lors de l’utilisation du pare-feu d’applications web Azure sur Application Gateway, lorsque la taille de la requête du client dépasse la limite maximale de taille du corps de la requête. Le champ de taille maximale du corps de la demande contrôle la limite totale de la taille de la demande, à l'exclusion de tout téléchargement de fichier. La valeur par défaut pour la taille du corps de la demande est de 128 Ko. Pour plus d’informations, consultez Limites de taille des requêtes adressées au pare-feu d’applications web.

499 - Le client a fermé la connexion

Une réponse HTTP 499 est présentée si une demande de client envoyée aux passerelles applicatives utilisant la référence SKU v2 est fermée avant que le serveur ne réponde. Cette erreur peut être observée dans deux scénarios. Le premier scénario est lorsqu’une réponse volumineuse est retournée au client et celui-ci a peut-être fermé ou actualisé l’application avant que le serveur n’ait terminé l’envoi d’une réponse volumineuse. Le deuxième scénario est le moment où le délai d’attente côté client est faible et n’attend pas suffisamment longtemps pour recevoir la réponse du serveur. Dans ce cas, il est préférable d’augmenter le délai d’attente sur le client. Dans les passerelles d’application utilisant la référence SKU V1, un code de réponse HTTP 0 peut également être déclenché pour le client fermant la connexion avant que le serveur ait terminé de répondre également.

Codes de réponse 5XX (erreur du serveur)

Les codes de réponse 500-599 indiquent qu’un problème s’est produit avec la passerelle applicative ou le serveur de back-end pendant l’exécution de la demande.

500 - Erreur interne du serveur

Azure Application Gateway ne doit pas présenter de codes de réponse 500. Ouvrez une demande d’assistance si vous voyez ce code, car il s’agit d’une erreur interne au service. Pour plus d’informations sur l’ouverture d’un cas de support, consultez Créer une demande de support Azure.

502 - Passerelle incorrecte

Les erreurs HTTP 502 peuvent avoir plusieurs causes racines, par exemple :

Pour plus d’informations sur les scénarios où les erreurs 502 se produisent et comment les résoudre, consultez Résoudre les erreurs de passerelle incorrecte.

504 – Délai d’attente de la passerelle dépassé

La référence SKU Application Gateway V2 a envoyé des erreurs HTTP 504 si le temps de réponse du serveur principal dépasse la valeur de délai d’attente configurée dans le paramètre de back-end.

IIS (serveur Web Internet Information Services)

Si votre serveur principal est IIS, consultez Les limites par défaut des sites web pour définir la valeur de délai d’attente. Pour plus d’informations, reportez-vous à l’attribut connectionTimeout. Vérifiez que le délai d’attente de connexion dans IIS correspond ou ne dépasse pas le délai d’attente défini dans le paramètre back-end.

Nginx

Si le serveur back-end est Nginx ou Nginx Ingress Controller, et s’il dispose de serveurs en amont, assurez-vous que la valeur de nginx:proxy_read_timeout correspond ou ne dépasse pas le délai d’attente défini dans le paramétrage du serveur back-end.

Scénarios de résolution des problèmes

Erreur « ERRORINFO_INVALID_HEADER » dans les journaux d’accès

Problème : le journal d’accès affiche une erreur « ERRORINFO_INVALID_HEADER » pour une requête, malgré le code de réponse back-end (serverStatus) étant 200. Dans d’autres cas, le serveur principal peut retourner 500.

Cause : le client envoie un en-tête contenant des caractères CR LF.

Solution : remplacez les caractères CR LF par sp (espace blanc) et renvoyez la requête à Application Gateway.

Étapes suivantes

Si les informations de cet article ne vous aident pas à résoudre le problème, envoyez un ticket de support.