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.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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 |
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.
Ücretsiz ön izlemeyi tamamladınız.