request response - intelguasoft/sistema-escolar GitHub Wiki

HTTP Request / Response Para ilustrar la forma en que un servidor web y un contenedor servlet trabajan juntos para prestar servicios a sus clientes, esta sección discute el protocolo seguido por una solicitud HTTP y su respuesta, desde el momento en que una solicitud de un cliente es recibido hasta que el servidor devuelve una respuesta. A pesar de que el navegador no es el único tipo de cliente que responde a este sistema, si que es el mas conocido y ampliamente usado.

HTTP se basa en un modelo solicitud / respuesta, de modo que hay dos tipos de mensajes HTTP: la solicitud y la respuesta. El navegador abre una conexión a un servidor y realiza una solicitud. El servidor procesa la solicitud del cliente y devuelve una respuesta. La figura siguiente ilustra este proceso.

Ambos mensajes consisten en una línea de salida, de cero o más campos de cabecera, y una línea vacía que indica el final de las cabeceras de los mensajes. Ambos tipos de mensajes también puede contener opcionalmente un cuerpo de mensaje.

El formato y la composición de los mensajes de solicitud y de respuesta son muy similares, pero hay unas pocas diferencias que veremos a continuacion.

La solicitud HTTP La línea de salida de una petición HTTP se conoce como línea de la petición. Siempre es la primera línea del mensaje de solicitud y contiene tres campos:

• Un método HTTP
• Un identificador universal de recursos (URI)
• Una versión del protocolo HTTP

Aunque hay varios métodos de HTTP para recuperar datos de un servidor, las dos más utilizados son GET y POST.

El método GET solicita un recurso del servidor indicado en el campo URI. Si la URI apunta a una base de datos de producción de recursos como un servlet, los datos serán devueltos dentro del mensaje de respuesta.

El método POST se utiliza para pasar explícitamente datos al servidor en el propio mensaje de solicitud.Estos datos estarán a disposición del recurso URI especificado en la solicitud.

En definitiva, el URI identifica el recurso que debe procesar la solicitud. Este URI se podrá especificar de forma absoluta o mediante una ruta relativa. Una solicitud con una URI no válida devolverá un código de error ( normalmente el error 404 ).

La versión de HTTP de la solicitud especifica la versión del protocolo HTTP usado. El siguiente ejemplo ilustra la línea de petición para una muestra GET

GET / index.html HTTP/1.0

Nota: Se puede ejecutar este comando mediante la apertura de una sesión Telnet a un servidor que ejecute un servidor web, a traves de una sentencia similar a

telnet localhost 80

donde se especifica el nombre del Host y el puerto. A continuación, lanzar el comando GET anterior. Habrá que presione Enter dos veces después de la emisión de la orden: una vez para el final de la línea de petición y de nuevo para permitir que el servidor sepa que se terminó con la petición. Suponiendo que hay un archivo llamado index.html en el directorio raíz, obtendremos el código HTML de respuesta.

Como se mencionó anteriormente, la petición HTTP puede contener cero o más campos de cabecera. Estos campos de cabecera permiten pasar al servidor informacion del propio cliente y de la solicitud misma. El formato de un campo de cabecera, tanto para la solicitud y la respuesta, es el nombre del campo de cabecera seguido de dos puntos (:) y el valor. Si se especifican varios valores para un único campo de cabecera, deben estar separados por comas. En la siguiente tabla se enumeran algunos de los más comúnmente utilizados.

Accept Indica que los tipos de medios son aceptables para la respuesta. En caso de que el campo Accept no aparezca en la cabecera el servidor puede asumir que el cliente acepta todos los tipos. Un ejemplo de un valor de la cabecera Accept es "image/gif, image/jpeg" Accept-Charset Indica lo que los conjuntos de caracteres son aceptables para la respuesta. Si éste campo no está presente en la solicitud, el servidor puede asumir que cualquier conjunto de caracteres es aceptable. La ISO-8859-1 juego de caracteres, puede suponerse que se aceptable por todos los agentes de usuario. Accept-Encoding Similar a la cabecera Accept campo, pero que restringe aún más los valores aceptados por el cliente. Un ejemplo de un Accept-Encoding es "compress, gzip". Accept-Languaje Indica los idiomas que el cliente prefiere para la respuesta. Un ejemplo de una cabecera Accept-Language es "en-us, de-li, es-us". Content-Encoding Indica el mecanismo de codificación que se ha aplicado al cuerpo del mensaje y, por lo tanto, qué mecanismo de decodificación debe utilizarse para obtener la información. Un ejemplo de un encabezado Content-Encoding es "gzip". Content-Type Indica el tipo del cuerpo del mensaje enviado al destinatario.Un valor posible para Content-Type es "text/html; charset = ISO-8859-1 Host Indica el nombre del host y el número de puerto de los recursos que se solicitan, obtenidos de la URL original.Un ejemplo de un encabezado de host puede ser "www.somehost.com" Referer Permite al cliente especificar la dirección (URI) de los recursos desde la que obtiene la respuesta. Esta cabecera se utiliza con propósitos de mantenimiento y seguimiento User-Agent Contiene información sobre el cliente que originó la petición. Esta cabecera se utiliza principalmente con fines estadísticos y de seguimiento. Un ejemplo de un User-Agent es "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5,0)" El cuerpo del mensaje de solicitud se utiliza para llevar a los datos del servidor asociado a la petición. Los datos incluidos en el cuerpo es diferente de los valores utilizados por los campos de cabecera tanto en términos de formato como del contenido. Los campos de cabecera puede ser pensado como metadatos sobre el cuerpo del mensaje.

La respuesta HTTP Una vez que el servidor ha recibido y procesado la solicitud, éste debe devolver un mensaje de respuesta HTTP hacia el cliente. El mensaje de respuesta se compone de una línea de estado y cero o más campos de cabecera, seguido por una línea vacía. También puede tener opcionalmente un cuerpo del mensaje.

La primera línea del mensaje de respuesta HTTP que se conoce como la línea de estado. Se compone de HTTP versión del protocolo que se ajusta a la respuesta, seguida por un código numérico y su estatuto de texto explicación. Cada campo está separado del siguiente por un espacio. Un ejemplo de línea de estado es la respuesta se muestra aquí: HTTP/1.1 200 OK El código de estado es de tres dígitos de un valor numérico que se corresponde con el resultado del código del servidor intento de satisfacer la petición. El código de estado es para aplicaciones de programación, mientras que el texto que lo acompaña está destinado a los lectores humanos. El primer dígito del código de estado define la categoría del resultado código.

La siguiente tabla enumera los primeros dígitos y permite ver las categorías correspondientes

Código de estado Significado del valor numérico

• 100-199 Informativo - La solicitud fue recibida y se está procesando.
• 200-299 Éxito - La acción fue recibida con éxito, entendido y aceptado.
• 300-399 Redireción - Otras peticiones hay que realizar para completar la petición.
• 400-499 Error en Cliente - La solicitud contiene mala sintaxis y no pueden llevarse a cabo.
• 500-599 Error de servidor - El servidor no pudo cumplir con una solicitud aparentemente válida.

Un buen número de códigos de estado se han definido. Ellos también son extensibles, lo que permite a las aplicaciones extender el comportamiento del servidor. Si una aplicación cliente no reconoce un código de estado devuelto por el servidor, se puede determinar el significado general de la respuesta mediante el uso de la primera cifra de la devolución código de estado. La siguiente tabla recoge algunas de las respuesta más común los códigos de estado. Código Significado OK-200 La solicitud éxito 302 Movido temporalmente-La solicitud de residencia temporal en un URI. Si el nuevo URI es un ubicación, la ubicación en el campo de encabezado de respuesta dará a la nueva URL. Este código normalmente se utiliza cuando el cliente se redirige 400 Bad Request-El servidor no puede comprender la solicitud debido a un error de sintaxis. 401-La solicitud no autorizada requiere autenticación y / o autorización. 403 Forbidden-El servidor entiende la petición, pero por alguna razón se niega a cumplirlo. El servidor puede o no puede revelar la razón por la que se niega la petición. 404 Not Found-El servidor no ha encontrado nada que coinciden con el URI de solicitud. 500-Internal Server Error "El servidor encontró un inesperado condición que le impidió el cumplimiento de la petición. Los campos de cabecera en la respuesta es similar en formato a las que se encuentran en el mensaje de solicitud. Ellos permitir que el servidor pasa al cliente información adicional que no puede ser colocado en la línea de estado. Estos campos proporcionan información sobre el servidor y un mayor acceso a los contenidos en la URI la petición. Después de la última respuesta de cabecera, que es seguida por una línea vacía, el servidor puede insertar la respuesta del cuerpo del mensaje. En muchos casos, la respuesta del cuerpo del mensaje es la salida HTML. Figura 2-4 ilustra un ejemplo de respuesta a la siguiente petición: GET / hello.html HTTP/1.0