http - error 504 whatsapp

Estado HTTP 504

Question

Recibo el siguiente error cuando mi aplicación win32 (c #) llama a servicios web.

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

Entiendo ''Creo'' que esto se debe a que la solicitud previa no recibe una respuesta de manera oportuna.

¿Pero mi pregunta es esta? ¿Cómo cambio la configuración de app.config en mi aplicación win32 para permitir más tiempo para procesar sus datos? Supongo que exijo que estos cambios se realicen en la configuración de mi aplicación, ya que los servicios web y el servidor IIS que aloja el ws están configurados con tiempos extendidos.

Esperamos una respuesta y gracias de antemano.

Scott

Answer 1

CheckUpDown tiene una buena explicación del error 504 :

Un servidor (no necesariamente un servidor web) actúa como una puerta de enlace o proxy para cumplir con la solicitud del cliente (por ejemplo, su navegador web o nuestro robot CheckUpDown) para acceder a la URL solicitada. Este servidor no recibió una respuesta oportuna de un servidor ascendente al que accedió para tratar su solicitud HTTP.

Esto generalmente significa que el servidor ascendente está inactivo (sin respuesta a la puerta de enlace / proxy), en lugar de que el servidor ascendente y la puerta de enlace / proxy no acepten el protocolo para intercambiar datos.

Este problema se debe enteramente a la comunicación IP lenta entre computadoras de servicios de fondo, que posiblemente incluye el servidor web. Solo las personas que configuran la red en el sitio que aloja el servidor web pueden solucionar este problema.

Answer 2

He tenido otro problema para darme un 504. Está bastante lejos pero lo escribiré aquí para googlers y posterity ...

Tengo un cliente llamando a un servicio web alojado en IIS alojado en otro dominio (Active Directory). No hay plena confianza entre el dominio del cliente y el dominio donde se alojan los servicios web. Uno de los muchos desafíos con la confianza selectiva entre estos dos dominios es que Kerberos no funciona cuando se llama de uno a otro.

En mi caso, estaba tratando de llamar a un servicio en otro dominio donde descubrí que se había registrado un SPN. Me gusta esto: http / myurl.test.local (solo un ejemplo)

Esto fuerza la llamada a usar Kerberos en lugar de dejar que vuelva a NTLM y esto me dio un 405 de vuelta desde el servidor de llamadas.

Después de eliminar el spn y permitir que la llamada vuelva a NTLM, funciona bien.

Como dije ... esto no es algo con lo que te encuentres, ya que la mayoría de las organizaciones no se aventuran a tener un fideicomiso tan selectivo entre dos dominios ... Pero da un 504 y me causó algunos (más) pelos grises .

Answer 3

No puedes. El problema no es que tu aplicación sea impaciente y se agote el tiempo; el problema es que un proxy intermedio es impaciente y el tiempo de espera. "El servidor, mientras actuaba como una puerta de enlace o proxy, no recibió una respuesta oportuna del servidor ascendente especificado por el URI". ( http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5.5 ) Lo más probable es que indique que el servidor de origen está teniendo algún tipo de problema, por lo que no responde rápidamente a la solicitud reenviada.

Posibles soluciones, ninguna de las cuales te hará feliz:

• Aumente el valor de tiempo de espera del proxy (si está bajo su control)
• Realice su solicitud a un servidor diferente (si hay otro servidor con la misma información)
• Haga su solicitud de manera diferente (si es posible) de manera que esté solicitando menos datos a la vez
• Inténtalo de nuevo una vez que el servidor no tenga problemas

Answer 4

Si utiliza ASP.Net 5 (ahora conocido como ASP.Net Core v1), asegúrese en su sección project.json "commands" para cada sitio que está hospedando que el puerto de escucha proxy de Kestrel difiere entre los sitios, de lo contrario, un sitio funcionará pero el otro devolverá un tiempo de espera de puerta de enlace 504.

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

Answer 5

Supongamos que accedemos a un servidor proxy A (por ejemplo, nginx) y el servidor A reenvía la solicitud a otro servidor B (por ejemplo, tomcat).

Si este proceso continúa durante un tiempo prolongado (más que la configuración de tiempo de espera de lectura del servidor proxy), A aún no obtuvo una respuesta completa de B. Sucede.

para nginx, puede configurar la propiedad proxy_read_timeout (in location) para resolver la suya. Pero esto generalmente no es una buena idea, si establece el valor demasiado alto. Esto puede ocultar el error real. Será mejor que mejore el diseño para resolver realmente este problema.

Answer 6

Tal vez se trata de la configuración de proxy de red. Mira eso http://rapid-i.com/rapidforum/index.php?topic=4436.0

Answer 7

Una cosa que he observado con respecto a este error es que aparece solo para la primera respuesta del servidor, que en el caso de http debe ser la respuesta de saludo. Una vez que se envía una respuesta inmediata del servidor a la puerta de enlace, si después de la respuesta principal toma tiempo, no da un error. La clave aquí es que la primera respuesta en una solicitud de un servidor debe ser rápida.