2012-10-11 36 views
6

Estaba trabajando con un colega que realizaba un trabajo que implica pasar URL de devolución de mi módulo a la suya. Debido a una mala configuración de su parte, la URL de devolución de llamada era diferente y llamaba una URL de su servidor, no la mía. Aparte de que hemos arreglado el error, durante ese mal configurado de devolución de llamada que recibió esta respuesta (que nunca he visto antes):Estado de HTTP 902 - No existe tal conversación

HTTP Status 902 - No such conversation 

Sólo por curiosidad Googled alrededor y no puedo encontrar ninguna especificación o descripción de este HTTP código de estado, y siempre pensé que los códigos de estado solo iban de 1XX a 5XX (como se explica en Section 10 of the HTTP 1.1 Spec)

¿Alguna idea de dónde puedo encontrar una especificación oficial (o no) que describa esto?

FYI el servidor en cuestión es un Tomcat 7.0.25

EDIT: Incluyendo la imagen de la respuesta

enter image description here

+0

¿Está absolutamente seguro de que esto proviene de Tomcat y no de otra biblioteca (o incluso de su propio código) que configura este código de respuesta? – mindas

+0

@mindas Nuestro código no está generando esta respuesta, así que estoy investigando en todas las bibliotecas incluidas que obtienen una referencia al respondedor para ver cuál exactamente está poniendo esto, pero aún no puede encontrarlo. Cavé antes en el código fuente del coyote y no pude encontrar ninguna referencia a una respuesta 902, así que todavía estoy cavando. La aplicación web usa 'spring-webmvc' pero no estoy seguro de si eso es relevante – betomontejo

+1

Usted escribió:" la URL de devolución de llamada fue diferente y llamó una URL de su servidor, no la mía ". ¿Podría el código 902 venir de una aplicación que fue llamada por error en su servidor? ¿Tiene acceso a su código fuente? Parece que alguien se volvió creativo y decidió inventar un código de estado personalizado para sus necesidades internas. –

Respuesta

1

Lo siento por todo el rumor, pero resultó que una biblioteca interna de la compañía reutilizada es la responsable de esto, por lo que NO está relacionado con Tomcat , ni Spring ni nada. Es simplemente un código de respuesta de la empresa propietaria.

Cuestiones relacionadas