Statut HTTP 504

Je reçois l’erreur suivante lorsque mon application win32 (c #) appelle des services Web.

The request failed with HTTP status 504: Gateway timeout server response timeout.

Je comprends «je pense» que c’est parce que la demande en amont ne reçoit pas de réponse dans les délais.

Mais ma question est la suivante? Comment puis-je modifier les parameters app.config dans mon application win32 pour accorder plus de temps au traitement de ses données. Je suppose que je souhaite que ces modifications soient apscopes aux parameters de mon application, car les services Web et IIS hébergeant les ws sont configurés avec des délais prolongés.

Réjouissez-vous d’une réponse et merci d’avance.

Scott

Vous ne pouvez pas Le problème n’est pas que votre application soit impatiente et que le temps soit écoulé; le problème est que le proxy intermédiaire est impatient et expire. “Le serveur, tout en agissant en tant que passerelle ou proxy, n’a pas reçu de réponse en temps voulu du serveur en amont spécifié par l’URI.” ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5 ) Cela indique très probablement que le serveur d’origine rencontre un problème, il ne répond donc pas rapidement à la demande transférée.

Des solutions possibles, dont aucune n’est susceptible de vous rendre heureux:

Augmenter la valeur du délai d’attente du proxy (s’il est sous votre contrôle)
Faites votre demande à un autre serveur (s’il y a un autre serveur avec les mêmes données)
Faites votre demande différemment (si possible) de manière à demander moins de données à la fois
Réessayez une fois que le serveur n’a pas de problème

CheckUpDown a une bonne explication de l’erreur 504 :

Un serveur (pas nécessairement un serveur Web) agit comme une passerelle ou un proxy pour répondre à la demande du client (par exemple, votre navigateur Web ou notre robot CheckUpDown) pour accéder à l’URL demandée. Ce serveur n’a pas reçu de réponse en temps opportun d’un serveur en amont auquel il a accédé pour gérer votre requête HTTP.

Cela signifie généralement que le serveur en amont est en panne (pas de réponse à la passerelle / au proxy), plutôt que le serveur en amont et la passerelle / proxy ne sont pas d’accord sur le protocole d’échange de données.

Ce problème est entièrement dû à la lenteur de la communication IP entre les ordinateurs principaux, y compris éventuellement le serveur Web. Seules les personnes ayant configuré le réseau sur le site qui héberge le serveur Web peuvent résoudre ce problème.

Supposons que vous accédiez à un serveur proxy A (par exemple, nginx) et que le serveur A transmette la demande à un autre serveur B (par exemple, tomcat).

Si ce processus se poursuit longtemps (plus que le paramètre de délai d’attente de lecture du serveur proxy), A n’a toujours pas reçu une réponse complète de B. Cela se produit.

pour nginx, vous pouvez configurer la propriété proxy_read_timeout (in location) pour résoudre le sien. Mais ce n’est généralement pas une bonne idée si vous définissez une valeur trop élevée. Cela peut cacher la vraie erreur. Vous feriez mieux d’améliorer la conception pour vraiment résoudre ce problème.

Si vous utilisez ASP.Net 5 (maintenant appelé ASP.Net Core v1), assurez-vous dans votre section project.json “Commandes” pour chaque site que vous hébergez que le port d’écoute du proxy Kestrel diffère d’un site à l’autre. autre retourne un délai d’attente de 504 passerelles.

  "commands": { "web": "Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5090" },

Une chose que j’ai observée concernant cette erreur est qu’elle n’apparaît que pour la première réponse du serveur, ce qui, en cas de http, devrait être la réponse de la poignée de main. Une fois qu’une réponse immédiate est envoyée du serveur à la passerelle, si la réponse principale prend du temps, elle ne génère pas d’erreur. La clé ici est que la première réponse sur une requête par un serveur devrait être rapide.

Peut-être est-ce à propos de vos parameters de proxy réseau. Regarde ça http://rapid-i.com/rapidforum/index.php?topic=4436.0

J’ai eu un autre numéro me donnant un 504. C’est assez éloigné mais je vais l’écrire ici pour les googleurs et la postérité …

J’ai un client qui appelle un service Web hébergé par IIS hébergé dans un autre domaine (Active Directory). Il n’y a pas de confiance totale entre le domaine client et le domaine sur lequel les services Web sont hébergés. L’un des nombreux défis liés à la confiance sélective entre ces deux domaines est que Kerberos ne fonctionne pas lors de l’appel de l’un à l’autre.

Dans mon cas, j’essayais d’appeler un service dans un autre domaine où j’ai découvert qu’un SPN était enregistré. Comme ceci: http / myurl.test.local (juste un exemple)

Cela oblige l’appel à utiliser Kerberos au lieu de le laisser retomber sur NTLM, ce qui m’a redonné un 405 du serveur appelant.

Après avoir supprimé le spn et avoir laissé l’appel à NTLM, cela fonctionne bien.

Comme je l’ai dit … ce n’est pas quelque chose que vous risquez de rencontrer, car la plupart des organisations ne se lancent pas dans des fiducies aussi sélectives entre deux domaines … Mais cela donne un 504 et me fait quelques cheveux gris .