Читать книгу: «Instalación y configuración del software de servidor web. IFCT0509», страница 3

3. Descripción de peticiones o request methods

Existen siete operaciones o métodos que se pueden solicitar a un servidor HTTP: OPTIONS, GET, HEAD, POST, PUT, DELETE y TRACE. Aunque existen todos estos tipos de comandos, el protocolo especifica que solo los comandos HEAD y GET deben ser implementados obligatoriamente en todo servidor HTTP.

3.1. Options

Este método representa una solicitud de información acerca de las opciones de comunicación disponibles para el canal petición/respuesta cuando se solicita un recurso al servidor. Permite al cliente determinar las opciones o requisitos asociados con un recurso, o capacidades de un servidor, sin que implique la transmisión del recurso a través del canal.

Cuando el recurso que se solicita es un asterisco (*), la petición se realiza sobre el servidor en general, no sobre un recurso específico. Por lo tanto, las opciones y capacidades especificadas en la respuesta serían aplicadas a cualquier recurso solicitado.

3.2. Get

Este método se usa para obtener alguna información (en forma de entidad). Esa información suele ser un recurso URI. Si la URI produce datos, serán esos datos los que se transmitirán en la respuesta.

El método también puede ser enviado bajo condicionantes. Estas condiciones son establecidas en las cabeceras de la petición y provocarán que el servidor envíe o no la respuesta en función de que se cumplan esas condiciones. Este mecanismo puede disminuir el tráfico a través de la red cuando existen muchas peticiones sobre el mismo recurso.

También existe la posibilidad de realizar una petición de GET parcial, lo que permite que el servidor solo transmita una parte del recurso. La especificación de esa parte estaría contenida en la cabecera “Range” del comando GET.

Actividades

3. Escriba el mensaje que debe enviar el navegador de internet si desea realizar una petición sobre la página de Google.

3.3. Head

Este método es el mismo que GET excepto que el servidor no devuelve el cuerpo de entidad en la respuesta.

La metainformación que devuelve HEAD debe ser la misma que devuelve GET para un mismo recurso. El método es usado frecuentemente para comprobar la validez de los enlaces, la accesibilidad y modificaciones recientes.

3.4. Post

Este método se usa para peticiones en las que el cliente pasa cierta información asociada con el recurso de la petición. POST está diseñado para cubrir las siguientes funciones:

1 Anotación de recursos existentes.

2 Enviar mensajes a un tablón de anuncios, grupo de noticias, listas de correos, o grupo de artículos similares.

3 Proporcionar un bloque de datos como resultado del envío de un formulario, para un proceso que maneje esos datos.

4 Realizar alguna consulta para la modificación o inserción en una base de datos.

Todas estas operaciones llevan a cabo tareas que modifican el estado del software que manejan, por lo que se trata de una operación que tiene efectos colaterales cuando se realiza la petición.

La función asociada al método POST es determinada por el servidor y por lo general depende del recurso URI. Además, dicha acción podría no dar como resultado un recurso que se pueda identificar mediante un URI.

Importante

GET debe ser utilizado siempre que la petición no implique ningún cambio en el software que la procesa, es decir, no hay efectos colaterales. Sin embargo, el método POST debe ser utilizado cuando la petición pueda afectar al estado del software desplegado en el servidor.

Actividades

4. Desea realizar una petición en una página web, pero esta se conecta a una base de datos para obtener la información que se muestra en la página. Explique brevemente qué tipo de petición debería realizar el navegador y por qué.

3.5. Put

El método PUT solicita que el cuerpo de entidad transmitido sea almacenado en el servidor como un recurso URI. Si ese recurso ya existiera, el servidor los consideraría como una versión modificada, mientras que si no existiera, el servidor definiría un nuevo recurso con la URI.

3.6. Delete

Este método solicita al servidor la eliminación del recurso identificado en la URI. Este método puede ser anulado en el servidor por parte del administrador. Por lo tanto, el cliente no puede garantizar que la operación se lleve a cabo, incluso aunque el estado de la respuesta lo haya indicado.

3.7. Trace

Este método permite al cliente ver si la petición está siendo recibida por el servidor y, en su respuesta, envía datos para que el cliente pueda testear y diagnosticar problemas en la comunicación. La información enviada en la petición es devuelta por el servidor.

4. Códigos de estado

Los códigos de estado son números de tres cifras que indican si la petición ha sido realizada correctamente y, si no, cuál es el motivo por el cual no se ha realizado. Existen cinco grandes grupos de estados, identificados por el primer dígito del número de estado:

1 1xx: son estados informativos. Indica una respuesta provisional, consistente en una línea de estado y cabeceras opcionales. No hay cabeceras requeridas para este tipo de estados. HTTP/1.0 no define ningún estado de este tipo, por lo que un servidor nunca debería responder con este código de estado a un cliente HTTP/1.0, salvo en condiciones experimentales. Además, el cliente debe estar preparado para aceptar una o más respuestas de este tipo antes de una respuesta normal.

2 2xx: son estados de éxito. Indican que la petición del cliente ha sido recibida, entendida y aceptada.

3 3xx: son estados de redirección. Esta clase de códigos de estado indican que, para realizar la petición solicitada, es necesario realizar acciones complementarias. La acción requerida podría ser llevada a cabo sin interacción con el usuario. Además, un cliente debe poder detectar bucles de redirecciones infinitos.

4 4xx: son estados de error en el cliente. Excepto cuando se responde a una petición HEAD, el servidor debería incluir una entidad que contenga la explicación de la situación de error, y si es temporal o permanente esa condición.

5 5xx: son estados de error en el servidor. El servidor envía este estado cuando encuentra una condición inesperada que le impide cumplir la petición del cliente.

La siguiente tabla muestra la mayoría de los códigos que se definen en el protocolo HTTP para el diálogo entre el agente de usuario y el servidor web:

Código	Comentario	Descripción
100	Continue	El cliente debe continuar con su petición.
101	Switching Protocols	El servidor entiende y está dispuesto a completar la petición y se modifica el campo de cabecera del mensaje para cambiar el protocolo de aplicación usado en la conexión.
200	OK	Operación realizada correctamente.
201	Created	La operación ha sido completada y el resultado es un nuevo recurso definido por la URI devuelta en el mensaje de respuesta.
202	Accepted	La operación ha sido completada y el resultado es un nuevo recurso definido por la URI devuelta en el mensaje de respuesta, pero el nuevo recurso no está disponible en ese momento. El mensaje debe indicar la disponibilidad del recurso.
204	No Content	El servidor ha realizado la petición y no necesita devolver información al cliente. Si el cliente es un agente de usuario, el documento que se está mostrando no debe alterarse.
205	Reset Content	El servidor ha realizado la petición y el agente de usuario debería reiniciar el documento que provocó el envío de la petición.
206	Partial Content	El servidor ha realizado la petición de un GET parcial para el recurso.
301	Moved Permanently	El recurso requerido ha sido asignado a un nuevo URI de forma permanente y cualquier referencia a este recurso debería usar la URI devuelta en el mensaje.
302	Found	El recurso requerido ha sido asignado a un nuevo URI de forma temporal y cualquier referencia a este recurso no debería ser modificada.
303	See Other	La respuesta a una petición puede ser encontrada en diferentes URI y debería ser reenviada usando un método GET sobre el recurso.
304	Not Modified	El cliente ha ejecutado un GET condicional y el acceso ha sido permitido, pero el documento no ha sido modificado.
305	Use Proxy	El recurso solicitado debe ser accedido a través del proxy devuelto por el campo “Location”.
306	(Unused)	Fue usado en versiones previas y en la actual está reservado.
400	Bad Request	La petición no puede ser entendida por el servidor debido a que posee un error de sintaxis.
401	Unauthorized	La petición requiere una autenticación. La respuesta contiene el protocolo de autentificación aceptado.
402	Payment Required	Este código está reservado para uso futuro.
403	Forbidden	El servidor entiende la petición, pero rechaza el envío de la respuesta. Está prohibido el acceso a este recurso, incluso con autentificación.
404	Not Found	El servidor no encuentra el recurso URI especificado en la petición.
405	Method Not Allowed	El servidor no permite el método solicitado para el recurso especificado en la petición.
406	Not Acceptable
407	Proxy Authentication Required	Este código es similar al 401, pero indica que el cliente debe autentificarse primero con el proxy.
408	Request Timeout	El cliente no ha producido una petición dentro del tiempo de espera del servidor.
409	Conflict	La petición no será completada debido a un conflicto en el estado actual del recurso. El mensaje debe dar la información necesaria para que el cliente resuelva el problema.
410	Gone	El recurso solicitado lleva mucho tiempo en estado no disponible y el servidor no reenviará una dirección conocida. Esta condición se espera que sea considerada como permanente.
411	Length Required	El servidor rechaza la petición porque falta el campo de cabecera “Content-Length”.
412	Precondition Failed	La precondición dada en las cabeceras de la petición ha sido evaluada como falsa cuando fue comprobada en el servidor.
413	Request Entity Too Large	El servidor rechaza el proceso de petición porque la entidad de la petición es más larga de lo que el servidor puede procesar.
414	Request-URI Too Long	El servidor rechaza el servicio de petición porque la URI solicitada es demasiado larga para que el servidor pueda interpretarla.
415	Unsupported Media Type	El servidor rechaza el servicio de petición porque la entidad de la petición está en un formato no soportado.
500	Internal Server Error	El servidor se encuentra en una condición no esperada que no permite completar la petición.
501	Not Implemented	El servidor no soporta la funcionalidad requerida para completar la petición.
502	Bad Gateway	El servidor, que actúa como proxy o pasarela, recibe una respuesta no válida del servidor original y no se ha permitido completar la petición.
503	Service Unavailable	El servidor está actualmente no disponible para manejar la petición debido a una sobrecarga o mantenimiento del servidor.
505	HTTP Version Not Supported	El servidor no soporta, o rechaza, la versión del protocolo enviado en la petición.

Actividades

5. Imagine que solicita una página web y el navegador le pregunta por un usuario y contraseña para acceder al recurso. Usted escribe su nombre de usuario y contraseña; y accede al recurso. Explique cuál habrá sido la secuencia de peticiones y respuestas (con sus códigos) que se habrá producido entre cliente y servidor para conseguir acceder al recurso.

5. Cabeceras

Existen tres tipos de cabeceras: las cabeceras generales, que se aplican tanto a las peticiones como a las respuestas, pero no al contenido de los mensajes; las cabeceras de petición, que permiten al cliente pasar información adicional al servidor sobre la petición y el propio cliente; y las de respuesta, que permiten al servidor pasar información adicional al cliente sobre la respuesta, el propio servidor y el recurso solicitado.

5.1. Cabeceras generales

Las cabeceras generales manejan información que puede ser utilizada tanto por clientes como por servidores, ya que se aplican a una sesión completa de comunicación. Pueden ser enviadas tanto en el interior de las peticiones como en el interior de las respuestas.

1 Cache-Control: es el campo de cabecera que se usa para especificar directivas que deben obedecer todos los mecanismos de caché para las peticiones y respuestas. Simplemente, esta cabecera configura el comportamiento que debe tener el agente de usuario y servidor origen respecto a la petición o respuesta en la caché.

2 Connection: este campo permite al emisor especificar opciones que son deseadas para una conexión particular. Entre sus opciones, se encuentra kee-alive, que permite conexiones persistentes y close, que provoca el cierre de la conexión para cada mensaje.

3 Date: es un campo que especifica la fecha y la hora en la que el mensaje fue generado. Los servidores de origen deben incluir esta cabecera en todas las respuestas, excepto en los siguientes casos:Si el estado de la respuesta es 100 o 101.Si el estado de la respuesta es un error, como 500 o 503.Si el servidor no tiene un reloj que pueda proporcionar una aproximación razonable del tiempo actual.

4 Pragma: este campo es usado para incluir directivas específicas de implementación que quizás se apliquen a algún mensaje a lo largo del canal de petición/respuesta. Todas las directivas especifican un comportamiento opcional desde el punto de vista del protocolo. Sin embargo, algunos sistemas pueden requerir que ese comportamiento sea consistente con las directivas.

5 Transfer-Encoding: es el campo que especifica el tipo de codificación que se ha realizado sobre el cuerpo del mensaje para una transferencia segura entre el emisor y el receptor.

6 Upgrade: permite especificar cuál es el protocolo de comunicación adicional que soporta el cliente y recomendaría usar si el servidor encuentra apropiado cambiar el protocolo.

7 Via: es usado por pasarelas y proxys para indicar los protocolos intermedios y recipientes entre el agente usuario y el servidor, sobre las peticiones, y entre el servidor origen y el cliente, sobre las respuestas.

5.2. Cabeceras de petición

Las cabeceras de petición son utilizadas por los agentes de usuario para enviar información adicional al servidor.

1 Accept: es usado para especificar ciertos tipos media que son aceptables por la respuesta.

2 Accept-Charset: puede ser usado para indicar qué conjunto de caracteres son aceptables para la respuesta.

3 Accept-Encoding: este campo es similar a Accept pero restringido a los “content-codings” que son aceptables en la respuesta.

4 Accept-Language: indica el conjunto de lenguajes naturales que son preferidos como respuesta de una petición.

5 Authorization: cuando un agente de usuario desea autentificarse con el servidor, después de haber recibido una respuesta de código 401, incluye este campo con la petición. Consiste en credenciales que contienen información de autentificación del agente usuario para obtener el recurso solicitado.

6 From: este campo debería contener la dirección de email del usuario que controla el agente de usuario. La interpretación de este campo es que la petición está siendo ejecutada en nombre de una persona, que acepta la responsabilidad del método ejecutado.

7 Host: especifica el host y el número de puerto del recurso que está siendo solicitado. Esto permite al servidor origen o pasarela diferenciar entre URL que son internamente ambiguas.

8 If-Modified-Since: este campo es uno de los que se utilizan para realizar peticiones condicionales. En este caso, el método de petición provocará una respuesta del servidor únicamente cuando se haya modificado el recurso después del momento especificado. En caso contrario, el servidor no devuelve el recurso y responde con un estado 304 (not modified).

9 If-Unmodified-Since: este campo tiene el comportamiento contrario al anterior. El método de petición provocará una respuesta del servidor origen solamente cuando el recurso solicitado no se haya modificado desde el momento especificado en este campo.

10 If-Match: en este caso, la respuesta del servidor origen debe contener alguna entidad cuya etiqueta corresponda con algún valor de etiquetas definido en este campo.

11 If-None-Match: este campo tiene el comportamiento contrario al anterior. En la respuesta del servidor origen no debe haber ninguna entidad cuya etiqueta corresponda con algún valor de etiquetas definido en este campo.

12 If-Range: este campo sirve para solicitar una copia parcial de un recurso. Se especifica cuál es el rango del recurso que se solicita y, si ese recurso no ha sido modificado, el trozo de recurso es enviado con la respuesta. Si, por el contrario, ha sido modificado, entonces la respuesta indicará que es necesario realizar una petición no parcial del recurso.

13 Max-Forwards: este campo proporciona un mecanismo con los métodos TRACE y OPTIONS para limitar el número de pasarelas que reenviarán la petición. Este campo se suele utilizar para trazar peticiones y encontrar bucles de reenvíos en la red.

14 Proxy-Authorization: este campo permite al cliente identificarse a un proxy que requiera autenticación. El valor de este campo consiste en credenciales que contienen la información de autenticación del usuario del agente para el recurso que está siendo solicitado.

15 Range: en este campo se especifica uno o varios rangos para especificar una petición parcial de un recurso.

16 Referer: este campo permite especificar, al servidor origen, la dirección del recurso desde el cual se ha realizado la petición. Referer no debe enviarse cuando la petición ha sido realizada desde un origen que no posee URI propia.

17 User-Agent: contiene información acerca del agente de usuario que origina la petición. Tiene propósitos estadísticos, aunque en la actualidad se ha intensificado su uso para determinar el dispositivo que realiza la petición y, de esta manera, enviar una respuesta con las limitaciones adecuadas.

Actividades

6. Observe el siguiente mensaje HTTP de petición en formato ASCII:

Comente la interpretación que debe hacer el servidor cuando reciba la petición.

Aplicación práctica

Imagine que solicita una página web index.html en el servidor www.prueba.com basado en Apache desde el navegador Mozilla FireFox. Sin embargo, esa página web requiere dos imágenes: imagen1.jpg (33948 bytes) e imagen2.jpg (4747 bytes) para componer el contenido. ¿Cómo es la secuencia de peticiones y respuestas que ocurren?

Cumplimente la tabla.

SOLUCIÓN

GET / HTTP/1.1 Host: www.prueba.com User-Agent: Mozilla/5.0 Accept: text/html Accept-Language: es-ES Connection: keep-alive	HTTP/1.1 200 Ok Date: Sun, 29 Sep xxxx xx:xx:xx GMT Server: Apache Content-Encoding: gzip Content-Length: XXX Connection: close Content-Type: text/html
GET /imagen1.jpg Host: www.prueba.com User-Agent: Mozilla/5.0 Accept: image/jpg Accept-Language: es-ES Accept-Encoding: gzip Connection: keep-alive	HTTP/1.1 200 OK Date: Sun, 29 Sep xxxx xx:xx:xx GMT Server: Apache Content-Type: image/jpeg Content-Length: 33948 Connection: keep-alive
GET /imagen2.jpg Host: www.prueba.com User-Agent: Mozilla/5.0 Accept: image/jpg Accept-Language: es-ES Accept-Encoding: gzip Connection: keep-alive	HTTP/1.1 200 OK Date: Sun, 29 Sep xxxx xx:xx:xx GMT Server: Apache Content-Type: image/jpeg Content-Length: 4747 Connection: keep-alive

5.3. Cabeceras de respuesta

Las cabeceras de respuesta son utilizadas por los servidores web para enviar información adicional al agente de usuario.

1 Age: este campo transmite una estimación de la cantidad de tiempo desde que se generó la respuesta en el servidor origen.

2 Location: es un campo que es usado para redirigir al receptor a la localización especificada para completar la petición.

3 Proxy-Authenticate: es el campo que indica al agente de usuario que para solicitar el recurso debe autentificarse, y lo indica enviando el esquema y los parámetros aplicados para la petición del recurso.

4 Retry-After: es usado con una respuesta 503 (Service Unavailable) para indicar cuánto tiempo se espera que el servicio no esté disponible para las peticiones del cliente.

5 Server: contiene información acerca del software que es usado por el servidor origen para manejar la petición.

6 Warning: es usado para transmitir información adicional sobre el estado o transformación de un mensaje que quizás no se ha reflejado en el mensaje.

7 WWW-Authenticate: debe ser incluido en las respuestas con código 401 (Unauthorized). El valor de este campo consiste en al menos una referencia que indica el esquema de autenticación y parámetros aplicables a la petición URI.

Cabeceras de entidad

Estas cabeceras aportan información sobre el contenido del mensaje o, si no hay contenido, sobre el recurso al que hace referencia la URL de la petición.

1 Allow: este campo contiene una lista con los métodos soportados aplicables al recurso especificado. El propósito de este campo es estrictamente informar al receptor de los métodos válidos asociados con el recurso.

2 Content-Base: indica la URI base para resolver las URI relativas.

3 Content-Encoding: este campo es usado como un modificador de un tipo de medio. Cuando está presente, su valor indica que se ha realizado una codificación y el tipo de esta sobre el cuerpo de entidad. Por lo tanto, hace falta un mecanismo de decodificación para obtener el tipo de medio utilizando la referencia de este campo.

4 Content-Language: este campo especifica el lenguaje natural de la audiencia a la que se destina la entidad adjunta.

5 Content-Length: especifica el tamaño del cuerpo entidad, en números decimales de octetos, que se envía, o en caso de un comando HEAD, el tamaño del cuerpo entidad si la petición tuviera un comando GET.

6 Content-Location: es usado para suministrar la localización del recurso para la entidad adjuntada en el mensaje cuando esa entidad es accesible desde una localización distinta del recurso URI de la petición.

7 Content-MD5: este campo contiene un MD5 del cuerpo entidad con el propósito de proporcionar integridad de la transmisión del mensaje. Es una buena forma de detectar modificaciones accidentales durante la transmisión del mensaje, pero no es el remedio contra ataques maliciosos.

8 Content-Range: es enviado con un cuerpo de entidad parcial para especificar en qué parte del cuerpo de entidad total debe ser aplicado.

9 Content-Type: este campo indica el tipo de medio que es enviado en el cuerpo de la entidad al cliente o, en el caso de una petición HEAD, el tipo de medio que sería enviado si la petición fuera un GET.

10 Etag: define una marca para todo el contenido asociado.

11 Expires: indica la fecha a partir de la cual la respuesta deja de ser válida.

12 Last-Modified: indica la fecha de la última modificación.

Actividades

7. Sea el siguiente mensaje HTTP de respuesta en formato ASCII:

Comente la interpretación que debe hacer el cliente cuando reciba la respuesta.