Codes de réponse HTTP dans Application Gateway

  • Article

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 englobent les demandes envoyées par le client à un nom d’hôte qui ne correspond pas, l’expiration du délai d’attente de la demande, 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 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 en pourcentage. Par exemple : %>
Version HTTP non valide Get /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 Authorization:<base64 encoded content>, Authorization: <base64 encoded content>
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 :

  • Le certificat client n’est pas présenté, mais l’authentification mutuelle est activée.
  • La validation ND est activée et le ND du certificat client ne correspond pas au ND de la chaîne de certificat 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 est activée et le certificat est révoqué.
  • La vérification de révocation du client OCSP est activée, mais elle ne peut pas être contactée.
  • La vérification de révocation du client OCSP 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 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 peut être renvoyée si une demande est envoyée à une passerelle applicative qui :

408 - Expiration du délai d’attente de la demande

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 lorsque le délai d’attente côté client est faible et ne suffit pas 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épassement du délai de la passerelle

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

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

nginx

Si le serveur principal est nginx ou le contrôleur d’entrée nginx, et s’il a des serveurs en amont, vérifiez que la valeur de nginx:proxy_read_timeout correspond au délai d’attente défini dans le paramètre de back-end ou ne le dépasse pas.

Étapes suivantes

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