org.apache.http.httpresponse jar
¿La respuesta HTTP "200 OK" da garantía de que la máquina que generó la solicitud HTTP recibió el documento? (6)
Tengo dos máquinas, A y B.
A envía una solicitud HTTP a B y solicita algún documento. B responde, envía el documento solicitado y muestra un mensaje de 200 OK, pero la máquina A se queja de que no se recibió el documento debido a una falla en la red.
¿El código HTTP 200 también funciona como un acuse de recibo del documento?
¿El código HTTP 200 también funciona como un reconocimiento de que el documento ha sido recibido?
No, en absoluto.
Ni siquiera es una garantía de que el documento se haya transmitido completamente.
El código de respuesta está en la primera línea del flujo de respuesta. El servidor podría fallar o desconectarse del cliente en cualquier lugar entre el envío de la primera línea y el último byte de la respuesta. Es posible que el servidor ni siquiera sepa que esto ha sucedido.
De hecho, no hay forma de que el servidor pueda saber si el cliente recibió una respuesta HTTP completa (o parcial). No hay provisión para un reconocimiento en el protocolo HTTP.
Ahora puede implementar un protocolo de aplicación sobre HTTP en el cual el cliente debe enviar una segunda solicitud HTTP al servidor para decir "sí, obtuve el documento". Pero esto implicaría alguna "lógica de aplicación" implementada en el navegador del usuario; Por ejemplo, en Javascript.
A envía una solicitud a B. Puede haber todo tipo de obstáculos para evitar que la solicitud llegue a B. En el caso de https, la solicitud puede llegar a B pero ser rechazada y cuenta como si no hubiera alcanzado B. En todos estos casos, B no enviará ningún estado en absoluto.
Una vez que la solicitud llega a B y ya no hay errores que fallan B, ni falla de hardware, etc. B examinará la solicitud y determinará qué hacer y qué estado informar. Si A solicitó un archivo que está allí y A tiene acceso permitido, B comenzará a enviar un "estado 200" junto con los datos del archivo.
De nuevo, todo tipo de cosas puede salir mal. A puede no recibir nada, o el "estado 200" sin datos o datos incompletos, etc. (Por "recibir" me refiero a que los datos llegan al cable Ethernet, oa través de WiFi).
Usualmente el usuario de A usará alguna biblioteca que maneje los bits feos. Con alguna biblioteca decente, el usuario puede esperar que reciba algún error o un estado completo con los datos correspondientes. Si un estado 200 llega a A con solo la mitad de los datos, el usuario (dependiendo del diseño de la biblioteca) recibirá un error, no un estado, y definitivamente no un estado 200.
O puede tener una biblioteca que informe el estado 200 y le diga "aquí están los primeros 2,000 bytes", "aquí están los siguientes 2,000 bytes" y así sucesivamente, y en algún momento cuando las cosas vayan mal, es posible que le digan "lo siento, ahí está". Fue un error, los datos están incompletos ".
Pero en general, el caso de que el usuario obtenga un estado 200 y no haya datos, no sucederá.
Absolutamente no. HTTP 200 es generado por el servidor, y solo significa que entendió la solicitud y cree que es capaz de cumplirla (por ejemplo, el archivo está realmente allí). Se pueden producir todo tipo de errores durante la transmisión del documento de respuesta completa (interrupción de la conexión de red, pérdida de paquetes, etc.) que no se mostrará en la respuesta HTTP, pero debe detectarse por separado.
Es muy simple ver que el código de respuesta 200 OK no puede ser una garantía de nada sobre el documento de respuesta. Se envía antes de que se transmita el documento, por lo que solo una violación de la causalidad podría permitirle depender de la recepción exitosa del documento. Solo sirve como indicador de que la solicitud se recibió correctamente y el servidor cree que puede cumplir con la solicitud. Si la solicitud requiere un procesamiento adicional (por ejemplo, ejecutar un script), en lugar de solo devolver un documento estático, el código de respuesta generalmente debe enviarse después de que se haya completado, por lo que normalmente es un indicador de que esto tuvo éxito (pero hay situaciones en las que no es factible, como solicitudes con conexiones persistentes y notificaciones push (la secuencia de comandos podría fallar más adelante).
En un nivel más general, nunca es posible proporcionar una garantía absoluta de que todos los mensajes se hayan recibido en cualquier protocolo, debido al problema de los dos generales . Ningún sistema de reconocimiento puede sortear esto, porque en algún momento tiene que haber un último reconocimiento; no hay forma de saber si esto se recibe con éxito, porque eso requeriría otro reconocimiento, lo que contradice la premisa de que fue la última.
HTTP está diseñado teniendo en cuenta la posibilidad de varios tipos de "middleboxes" - proxies que operan con o sin el conocimiento del cliente.
Si hay un proxy involucrado, incluso sabiendo que el servidor había transmitido todos los datos y recibido una conexión cercana normal no le diría nada sobre si el documento que ha generado la solicitud HTTP ha recibido el documento.
Una guía bastante buena para el protocolo HTTP se encuentra aquí: http://blog.catchpoint.com/2010/09/17/anatomyhttp/
Debe hacer una distinción entre el protocolo HTTP y el protocolo de transporte de flujo subyacente, que debe ser confiable para propósitos HTTP. El protocolo de transporte de flujo reconocerá todas las transmisiones de datos, incluida la respuesta, de modo que ambos extremos del intercambio afirmarán que los datos se transmiten correctamente. Si el flujo de transporte falla, obtendrá un ''error de red'' o un error similar. Cuando esto sucede, el protocolo HTTP no puede continuar; Los datos ya no son confiables o incluso completos.
Lo que significa un mensaje 200 OK, a nivel HTTP, es que el servidor tiene el documento que está buscando y está a punto de transmitírselo. Normalmente, también obtendrá un encabezado de longitud de contenido, por lo que podrá determinar si / cuando el cuerpo está completo como una verificación adicional en la parte superior del protocolo de transmisión. Desde la perspectiva del protocolo HTTP, una respuesta no recibe confirmación, por lo que una vez que se ha enviado una respuesta, no hay verificación.
Sin embargo, como el transporte de flujo es confiable, el acto de enviar la respuesta tendrá éxito o resultará en un error. Esto verifica si el objetivo de la red ha recibido el documento (como señala TripeHound, en el caso de una conexión no directa, por ejemplo, un proxy, esto no es una garantía de entrega al objetivo final).