Hola,
Muchas gracias por las respuestas. Tengo varios comentarios:
1. Cuando yo hablo de que no explica como detectar la verdadera causa del error me refiero a que, si alguno de los lados cierra la conexión, debe ser por un motivo. Uno, el caso normal que no debe considerarse como error, lo explican como causado por la misma convención del protocolo; pero, el otro, o sea cuando es un verdadero error, no explican que puede causarlo ni como detectarlo en nuestro código, ya que decir que uno de los dos lados cierra la conexión es indicar la manifestación final; pero no la causa original.
Para ponerlo más claro en términos de códigos, lo ilustro con mi metodología:
Cuando tengo una serie de llamadas anidadas, en cada una de las cuales se pueden producir errores, yo voy atrapandolos en cada una de ellas, y lo hago con un mensaje que muestra un código de error y una descripción del mismo correspondiente al bloque; al final incluyo, el error que viene de la rutina inmediatamente anidada. De esta forma, el mensaje final de error es largo (incluso 4 o 5 anidados); pero permite determinar la ruta exacta del error.
Según la explicación dada para este problema de conexión, aparentemente se
dispara el mensaje más interno y no se incluye ninguna información de porque o donde se generó. Igualmente, no indica que deberíamos revisar cuando se trate de verdaderos errores.
Por lo anterior, aún cuando he leído con cuidado los mismos parrafos que publicas de esa nota (y toda la nota), no estoy de acuerdo en que sea una explicación completa para la situación.
2. Mi código para atrapar errores es metodológicamente muy robusto, como habrás notado de la observación anterior. En mi caso, aparte de desplegar mensajes de error largos, no solo atrapo los códigos de error propios de la convención; sino que también una serie de códigos de error personalizados que envío para detectar acciones que requieren manejo especial. De hecho, atrapo todo lo posible, no solo lo probable.
En el caso de nuestro mensaje, la excepción se dispara; pero el servidor
está enviando el código 200. Debido a eso, inicialmente me sorprendió porque no estaba usando el "Exception" para analizar el mensaje, sino que cuando atrapaba la excepción, solo validaba usando ResponseText y ResponseCode. Obviamente, ya cambié ese código porque ya no confío exclusivamente en los códigos de error del servidor.
3. Cuando dices:
Cita:
Empezado por jachguate
Aún cuándo la llamada sea la misma, puede ser que algo ocurra en el servidor y no estés procesando correctamente la respuesta. Por ejemplo, un servidor podría devolver un error 500 debido a una condición interna de error e inmediatamente después cerrar la conexión.
|
Entiendo que me estás dando la razón de que hay algún problema en el servidor; pero es un problema específico de la llamada, y la gran pregunta es por qué a veces contesta perfecto y en otras no dice nada ?. Considerando que encima el requerimiento es sin parámetros, resulta aún más extraño, ya que todas las veces debería hacer exactamente el mismo recorrido. Una de las dos grandes preguntas por las que abrí este hilo es : Como hacer para detectar la causa de estos casos ?
4. He usado, y uso, las versiones 8, 9 y 10 de Indy. En este momento, el
problema se presenta en la versión 10 que viene con el Update 3 de Delphi.
De todas formas, cuando digo que no parece algo relacionado con la versión es porque me pasa con la última (o casi última, no me he fijado si sacaron algo más) y he leído referencias de personas que lo han sufrido en diversas versiones.
5. Veo que no comentastes nada acerca de como manejarlo ?. Que metodología usas ?
Muchos saludos