Linux Professional Institute Learning Logo.
Pasar al contenido principal
  • Inicio
    • Todos los recursos
    • LPI Learning Materials
    • Conviértete en colaborador
    • Publishing Partners
    • Conviértase en un Publishing Partner
    • Acerca de nosotros
    • FAQ
    • Colaboradores
    • Roadmap
    • Contáctenos
  • LPI.org
031.3 Lección 1
Tema 031: Desarrollo de Software y Tecnologías Web
031.1 Conceptos básicos de desarrollo de software
  • 031.1 Lección 1
031.2 Arquitectura de aplicaciones web
  • 031.2 Lección 1
031.3 Conceptos básicos de HTTP
  • 031.3 Lección 1
Tema 032: Marcado de documentos HTML
032.1 Anatomía del documento HTML
  • 032.1 Lección 1
032.2 HTML Semántica HTML y jerarquía de documentos
  • 032.2 Lección 1
032.3 Referencias HTML y recursos incrustados
  • 032.3 Lección 1
032.4 Formularios HTML
  • 032.4 Lección 1
Tema 033: Estilo de contenido CSS
033.1 Conceptos básicos de CSS
  • 033.1 Lección 1
033.2 Selectores CSS y aplicación de estilo
  • 033.2 Lección 1
033.3 Estilo CSS
  • 033.3 Lección 1
033.4 Modelo y diseño CSS
  • 033.4 Lección 1
Tema 034: Programación JavaScript
034.1 Ejecución y sintaxis de JavaScript
  • 034.1 Lección 1
034.2 Estructuras de datos en JavaScript
  • 034.2 Lección 1
034.3 Funciones y estructuras de control de JavaScript
  • 034.3 Lección 1
  • 034.3 Lección 2
034.4 Manipulación JavaScript del contenido y estilo del sitio web
  • 034.4 Lección 1
Tema 035: Programación NodeJS server
035.1 Conceptos básicos de Node.js
  • 035.1 Lección 1
035.2 Conceptos básicos de NodeJS Express
  • 035.2 Lección 1
  • 035.2 Lección 2
035.3 Conceptos básicos de SQL
  • 035.3 Lección 1
How to get certified
  1. Tema 031: Desarrollo de Software y Tecnologías Web
  2. 031.3 Conceptos básicos de HTTP
  3. 031.3 Lección 1

031.3 Lección 1

Certificación:

Conceptos básicos de desarrollo web

Versión:

1.0

Tema:

031 Desarrollo de software y tecnologías web

Objetivo:

031.3 Conceptos básicos de HTTP

Lección:

1 de 1

Introducción

El HyperText Transfer Protocol (HTTP) define cómo un cliente solicita al servidor un recurso específico. Su principio de funcionamiento es bastante simple: el cliente crea un mensaje de solicitud identificando el recurso que necesita y reenvía ese mensaje al servidor a través de la red. A su vez, el servidor HTTP evalúa dónde extraer el recurso solicitado y envía un mensaje de respuesta al cliente. El mensaje de respuesta contiene detalles sobre el recurso solicitado, seguido del recurso en sí.

Más específicamente, HTTP es el conjunto de reglas que definen cómo la aplicación cliente debe formatear los mensajes request que se enviarán al servidor. Luego, el servidor sigue las reglas HTTP para interpretar la solicitud y formatear los mensajes reply. Además de solicitar o transferir el contenido solicitado, los mensajes HTTP contienen información adicional sobre el cliente y el servidor involucrados, sobre el contenido en sí e incluso sobre su indisponibilidad. Si no se puede enviar un recurso, un código en la respuesta explica el motivo de la indisponibilidad y, si es posible, indica hacia dónde se movió el recurso.

La parte del mensaje que define los detalles del recurso y otra información de contexto se denomina header. La parte que sigue al encabezado, y que contiene el contenido del recurso correspondiente, se llama payload del mensaje. Tanto los mensajes de solicitud como los de respuesta pueden tener un payload, pero en la mayoría de los casos, solo el mensaje de respuesta tiene uno.

Solicitud del cliente

La primera etapa de un intercambio de datos HTTP entre el cliente y el servidor es iniciada por el primero, cuando escribe un mensaje de solicitud en el servidor. Tomemos, por ejemplo, una tarea común del navegador: cargar una página HTML desde un servidor que aloja un sitio web, como https://learning.lpi.org/en/. La dirección, o URL, proporciona varios datos relevantes. En este ejemplo en particular, aparecen tres datos:

  • El protocolo: Protocolo de transferencia de hipertexto seguro (https), una versión encriptada de HTTP.

  • El nombre de dominio del proveedor de alojamiento web (learning.lpi.org)

  • La ubicación del recurso solicitado en el servidor (el directorio /en/ — en este caso, la versión en inglés de la página de inicio).

Note

Un Uniform Resource Locator (URL) es una dirección que apunta a un recurso en Internet. Este recurso suele ser un archivo que se puede copiar desde un servidor remoto, pero las URL también pueden indicar contenido generado dinámicamente y flujos de datos.

Cómo maneja el cliente la URL

Antes de contactar al servidor, el cliente necesita convertir learning.lpi.org a su dirección IP correspondiente. El cliente utiliza otro servicio de Internet, el Domain Name System (DNS), para solicitar la dirección IP de un nombre de host de uno o más servidores DNS predefinidos (los servidores DNS suelen definirse automáticamente por el proveedor de servicios de Internet, ISP).

Con la dirección IP del servidor, el cliente intenta conectarse al puerto HTTP o HTTPS. Los puertos de red son números de identificación definidos por el Transmission Control Protocol (TCP) para entrelazar e identificar distintos canales de comunicación dentro de una conexión cliente/servidor. De forma predeterminada, los servidores HTTP reciben solicitudes en los puertos TCP 80 (HTTP) y 443 (HTTPS).

Note

Existen otros protocolos utilizados por las aplicaciones web para implementar la comunicación cliente/servidor. Para llamadas de audio y video, por ejemplo, es más apropiado usar WebSockets, un protocolo de nivel inferior que es más eficiente que HTTP para transferir flujos de datos en ambas direcciones.

El formato del mensaje de solicitud que el cliente envía al servidor es el mismo en HTTP y HTTPS. HTTPS ya se usa más ampliamente que HTTP, porque todos los intercambios de datos entre el cliente y el servidor están encriptados, lo cual es una característica indispensable para promover la privacidad y la seguridad en las redes públicas. La conexión cifrada se establece entre el cliente y el servidor incluso antes de que se intercambie cualquier mensaje HTTP, utilizando el protocolo criptográfico Transport Layer Security (TLS). Al hacer esto, TLS encapsula toda la comunicación HTTPS. Una vez descifrada, la solicitud o respuesta transmitida a través de HTTPS no es diferente de una solicitud o respuesta realizada exclusivamente a través de HTTP.

El tercer elemento de nuestra URL, /en/, será interpretado por el servidor como la ubicación o ruta del recurso que se solicita. Si la ruta no se proporciona en la URL, se utilizará la ubicación predeterminada /. La implementación más simple de un servidor HTTP asocia rutas en URL con archivos en el sistema de archivos donde se ejecuta el servidor, pero esta es solo una de las muchas opciones disponibles en servidores HTTP más sofisticados.

El mensaje de solicitud

HTTP opera a través de una conexión ya establecida entre cliente y servidor, generalmente implementada en TCP y cifrada con TLS. De hecho, una vez que una conexión que cumple con los requisitos impuestos por el servidor está lista, una solicitud HTTP escrita a mano en texto sin formato podría generar la respuesta del servidor. En la práctica, sin embargo, los programadores rara vez necesitan implementar rutinas para componer mensajes HTTP, ya que la mayoría de los lenguajes de programación proporcionan mecanismos que automatizan éste proceso. En el caso de la URL de ejemplo, https://learning.lpi.org/en/, el mensaje de solicitud más simple posible tendría el siguiente contenido:

GET /en/ HTTP/1.1
Host: learning.lpi.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
Accept: text/html

La primera palabra de la primera línea identifica el método HTTP. Define qué operación desea realizar el cliente en el servidor. El método GET informa al servidor que el cliente solicita el recurso que le sigue: /en/. Tanto el cliente como el servidor pueden admitir más de una versión del protocolo HTTP, por lo que la versión que se adoptará en el intercambio de datos también se proporciona en la primera línea: HTTP/1.1.

Note

La versión más reciente del protocolo HTTP es HTTP/2. Entre otras diferencias, los mensajes escritos en HTTP/2 se codifican en una estructura binaria, mientras que los mensajes escritos en HTTP/1.1 se envían en texto sin formato. Este cambio optimiza las velocidades de transmisión de datos, pero el contenido de los mensajes es básicamente el mismo.

El encabezado puede contener más líneas después de la primera para contextualizar y ayudar a identificar la solicitud al servidor. El campo de encabezado Host, por ejemplo, puede parecer redundante, porque el host del servidor obviamente ha sido identificado por el cliente para establecer la conexión y es razonable suponer que el servidor conoce su propia identidad. No obstante, es importante informar al host del nombre de host esperado en el encabezado de la solicitud, porque es una práctica común utilizar el mismo servidor HTTP para alojar más de un sitio web. (En este escenario, cada host específico se denomina virtual host). Por lo tanto, el servidor HTTP utiliza el campo Host para identificar a cuál se refiere la solicitud.

El campo de encabezado User-Agent contiene detalles sobre el programa cliente que realiza la solicitud. Este campo puede ser utilizado por el servidor para adaptar la respuesta a las necesidades de un cliente específico, pero se utiliza más a menudo para producir estadísticas sobre los clientes que utilizan el servidor.

El campo Accept tiene un valor más inmediato, porque informa al servidor sobre el formato del recurso solicitado. Si el cliente es indiferente sobre el formato del recurso, el campo Accept puede especificar */* como el formato predefinido.

Hay muchos otros campos de encabezado que se pueden usar en un mensaje HTTP, pero los campos que se muestran en el ejemplo son suficientes para solicitar un recurso del servidor.

Además de los campos del encabezado de la solicitud, el cliente puede incluir otros datos complementarios en la solicitud HTTP que se enviará al servidor. Si estos datos constan solo de parámetros de texto simples, en el formato name=value, se pueden agregar a la ruta del método GET. Los parámetros están incrustados en la ruta después de un signo de interrogación y están separados por el caracter (&):

GET /cgi-bin/receive.cgi?name=LPI&email=info@lpi.org HTTP/1.1

En este ejemplo, /cgi-bin/receive.cgi es la ruta al script en el servidor que procesará y posiblemente usará los parámetros name e email, obtenidos de la ruta de la solicitud. La cadena que corresponde a los campos, en el formato name=LPI&email=info@lpi.org, se llama query string y es suministrada al script receive.cgi por el servidor HTTP que recibe la solicitud.

Cuando los datos se componen de más que campos de texto cortos, es más apropiado enviarlos en el payload del mensaje. En este caso, se debe utilizar el método HTTP POST para que el servidor reciba y procese el payload del mensaje, de acuerdo con las especificaciones indicadas en el encabezado de la solicitud. Cuando se utiliza el método POST, el encabezado de la solicitud debe proporcionar el tamaño del payload que se enviará a continuación y cómo se formatea el cuerpo:

POST /cgi-bin/receive.cgi HTTP/1.1
Host: learning.lpi.org
Content-Length: 1503
Content-Type: multipart/form-data; boundary=------------------------405f7edfd646a37d

El campo Content-Length indica el tamaño en bytes de la carga útil y el campo Content-Type indica su formato. El formato multipart/form-data es el más comúnmente utilizado en los formularios HTML tradicionales que utilizan el método POST. En este formato, cada campo insertado en el payload de la solicitud está separado por el código indicado por la palabra clave boundary. El método POST debe usarse solo cuando sea apropiado, ya que usa una cantidad de datos ligeramente mayor que una solicitud equivalente realizada con el método GET. Debido a que el método GET envía los parámetros directamente en el encabezado del mensaje de la solicitud, el intercambio total de datos tiene una latencia más baja, ya que no será necesaria una etapa de conexión adicional para transmitir el cuerpo del mensaje.

El encabezado de respuesta

Una vez que el servidor HTTP recibe el encabezado del mensaje de solicitud, el servidor devuelve un mensaje de respuesta al cliente. Una solicitud de archivo HTML normalmente tiene un encabezado de respuesta como este:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 18170
Content-Type: text/html
Date: Mon, 05 Apr 2021 13:44:25 GMT
Etag: "606adcd4-46fa"
Last-Modified: Mon, 05 Apr 2021 09:48:04 GMT
Server: nginx/1.17.10

La primera línea proporciona la versión del protocolo HTTP utilizada en el mensaje de respuesta, que debe corresponder a la versión utilizada en el encabezado de la solicitud. Luego, todavía en la primera línea, aparece el código de estado de la respuesta, indicando cómo el servidor interpretó y generó la respuesta a la solicitud.

El código de estado es un número de tres dígitos, donde el dígito más a la izquierda define la clase de respuesta. Hay cinco clases de códigos de estado, numerados del 1 al 5, cada uno de los cuales indica un tipo de acción realizada por el servidor:

1xx (Informational)

Se recibió la solicitud, continuando el proceso.

2xx (Successful)

La solicitud fue recibida, comprendida y aceptada con éxito.

3xx (Redirection)

Es necesario realizar más acciones para completar la solicitud.

4xx (Client Error)

La solicitud contiene una sintaxis incorrecta o no se puede cumplir.

5xx (Server Error)

El servidor no cumplió con una solicitud aparentemente válida.

El segundo y tercer dígitos se utilizan para indicar detalles adicionales. El código 200, por ejemplo, indica que la solicitud podría ser respondida sin problemas. Como se muestra en el ejemplo, también se puede proporcionar una breve descripción de texto después del código de respuesta (OK). Algunos códigos específicos son de particular interés para garantizar que el cliente HTTP pueda acceder al recurso en situaciones adversas o para ayudar a identificar el motivo del error en caso de que una solicitud no sea satisfactoria:

301 Moved Permanently

Al recurso de destino se le ha asignado una nueva URL permanente, proporcionada por el campo de encabezado Location en la respuesta.

302 Found

El recurso de destino reside temporalmente en una URL diferente.

401 Unauthorized

La solicitud no se ha aplicado porque carece de credenciales de autenticación válidas para el recurso de destino.

403 Forbidden

La respuesta Forbidden indica que, aunque la solicitud es válida, el servidor está configurado para no proporcionarla.

404 Not Found

El servidor de origen no encontró una representación actual para el recurso de destino o no está dispuesto a revelar que existe.

500 Internal Server Error

El servidor encontró una condición inesperada que le impidió cumplir con la solicitud.

502 Bad Gateway

El servidor, mientras actuaba como puerta de enlace o proxy, recibió una respuesta no válida de un servidor entrante al que accedió mientras intentaba cumplir con la solicitud.

Aunque indican que no fue posible cumplir con la solicitud, los códigos de estado 4xx y 5xx al menos indican que el servidor HTTP se está ejecutando y es capaz de recibir solicitudes. Los códigos 4xx requieren que se realice una acción en el cliente, porque su URL o credenciales son incorrectas. Por el contrario, los códigos 5xx indican algo incorrecto en el lado del servidor. Por lo tanto, en el contexto de las aplicaciones web, estas dos clases de códigos de estado indican que el origen del error se encuentra en la propia aplicación, ya sea cliente o servidor, no en la infraestructura subyacente.

Contenido estático y dinámico

Los servidores HTTP utilizan dos mecanismos básicos para cumplir con el contenido solicitado por el cliente. El primer mecanismo proporciona contenido estático: es decir, la ruta indicada en el mensaje de solicitud corresponde a un archivo en el sistema de archivos local del servidor. El segundo mecanismo proporciona contenido dinámico: es decir, el servidor HTTP reenvía la solicitud a otro programa, probablemente un script, para generar la respuesta a partir de diferentes fuentes, como bases de datos y otros archivos.

Aunque existen diferentes servidores HTTP, todos utilizan el mismo protocolo de comunicación HTTP y adoptan más o menos las mismas convenciones. Una aplicación que no tiene una necesidad específica se puede implementar con cualquier servidor tradicional, como Apache o NGINX. Ambos son capaces de generar contenido dinámico y proporcionar contenido estático, pero existen sutiles diferencias en la configuración de cada uno.

La ubicación de los archivos estáticos que se entregarán, por ejemplo, se define de diferentes formas en Apache y NGINX. La convención es mantener estos archivos en un directorio específico para este propósito, con un nombre asociado con el host, por ejemplo, /var/www/learning.lpi.org/. En Apache, esta ruta está definida por la directiva de configuración DocumentRoot /var/www/learning.lpi.org, en una sección que define un host virtual. En NGINX, la directiva utilizada es root /var/www/learning.lpi.org en la sección de server del archivo de configuración.

Cualquiera que sea el servidor que elija, los archivos en /var/www/learning.lpi.org/ se servirán a través de HTTP casi de la misma manera. Algunos campos en el encabezado de respuesta y su contenido pueden variar entre los dos servidores, pero campos como Content-Type deben estar presentes en el encabezado de respuesta y deben ser consistentes en cualquier servidor.

Almacenamiento en caché

HTTP fue diseñado para funcionar en cualquier tipo de conexión a Internet, rápida o lenta. Además, la mayoría de los intercambios HTTP tienen que atravesar muchos nodos de red debido a la arquitectura distribuida de Internet. Como resultado, es importante adoptar alguna estrategia de almacenamiento en caché para evitar la transferencia redundante de contenido descargado previamente. Las transferencias HTTP pueden funcionar con dos tipos básicos de caché: shared y private.

Más de un cliente utiliza una caché compartida. Por ejemplo, un gran proveedor de contenido puede utilizar cachés en servidores distribuidos geográficamente, de modo que los clientes obtengan los datos de su servidor más cercano. Una vez que un cliente ha realizado una solicitud y su respuesta se almacenó en una caché compartida, otros clientes que realicen la misma solicitud en esa misma área recibirán la respuesta en caché.

El propio cliente crea una caché privada para su uso exclusivo. Es el tipo de almacenamiento en caché que hace el navegador web para imágenes, archivos CSS, JavaScript o el documento HTML en sí, por lo que no es necesario volver a descargarlos si se solicita en un futuro próximo.

Note

No todas las solicitudes HTTP deben almacenarse en caché. Una solicitud que utiliza el método POST, por ejemplo, implica una respuesta asociada exclusivamente con esa solicitud en particular, por lo que su contenido de respuesta no debe reutilizarse. De forma predeterminada, solo se almacenan en caché las respuestas a las solicitudes realizadas mediante el método GET. Además, solo las respuestas con códigos de estado concluyentes como 200 (OK), 206 (Partial Content), 301 (Moved Permanently) y 404 (Not Found) son adecuadas para el almacenamiento en caché.

Tanto la estrategia de caché compartida como la privada utilizan encabezados HTTP para controlar cómo se debe almacenar el contenido descargado. Para la caché privada, el cliente consulta el encabezado de respuesta y verifica si el contenido de la caché local todavía corresponde al contenido remoto actual. Si lo hace, el cliente renuncia a la transferencia del payload de respuesta y usa la versión local.

La validez del recurso almacenado en caché se puede evaluar de varias formas. El servidor puede proporcionar una fecha de vencimiento en el encabezado de respuesta para la primera solicitud, de modo que el cliente descarta el recurso almacenado en caché al final del plazo y lo solicita nuevamente para obtener la versión actualizada. Sin embargo, el servidor no siempre puede determinar la fecha de vencimiento de un recurso, por lo que es común usar el campo de encabezado de respuesta ETag para identificar la versión del recurso, por ejemplo, Etag: "606adcd4-46fa".

Para verificar que un recurso almacenado en caché necesita actualizarse, el cliente solicita solo su encabezado de respuesta del servidor. Si el campo ETag coincide con el de la versión almacenada localmente, el cliente reutiliza el contenido almacenado en caché. De lo contrario, el contenido actualizado del recurso se descarga del servidor.

Sesiones HTTP

En un sitio web o aplicación web convencional, las funciones que manejan el control de sesión se basan en encabezados HTTP. El servidor no puede asumir, por ejemplo, que todas las solicitudes que provienen de la misma dirección IP son del mismo cliente. El método más tradicional que permite al servidor asociar diferentes solicitudes a un solo cliente es el uso de cookies, una etiqueta de identificación que le da el servidor al cliente y que se proporciona en el encabezado HTTP.

Las cookies permiten al servidor conservar información sobre un cliente específico, incluso si la persona que ejecuta el cliente no se identifica explícitamente. Con las cookies, es posible implementar sesiones donde los inicios de sesión, tarjetas de compra, preferencias, etc., se conservan entre diferentes solicitudes realizadas al mismo servidor que las proporcionó. Las cookies también se utilizan para rastrear la navegación del usuario, por lo que es importante solicitar su consentimiento antes de enviarlas.

El servidor establece la cookie en el encabezado de respuesta utilizando el campo Set-Cookie. El valor del campo es un par name=value elegido para representar algún atributo asociado con un cliente específico. El servidor puede, por ejemplo, crear un número de identificación para un cliente que solicita un recurso por primera vez y pasarlo al cliente en el encabezado de respuesta:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Set-Cookie: client_id=62b5b719-fcbf

Si el cliente permite el uso de cookies, las nuevas solicitudes a este mismo servidor tienen el campo de cookies en el encabezado:

GET /en/ HTTP/1.1
Host: learning.lpi.org
Cookie: client_id=62b5b719-fcbf

Con este número de identificación, el servidor puede recuperar definiciones específicas para el cliente y generar una respuesta personalizada. También es posible utilizar más de un campo Set-Cookie para entregar diferentes cookies al mismo cliente. De esta forma, se puede conservar más de una definición en el lado del cliente.

Las cookies plantean tanto problemas de privacidad como posibles agujeros de seguridad, porque existe la posibilidad de que se puedan transferir a otro cliente, que será identificado por el servidor como el cliente original. Las cookies utilizadas para conservar sesiones pueden dar acceso a información confidencial del cliente original. Por tanto, es muy importante que los clientes adopten mecanismos de protección local para evitar que sus cookies sean extraídas y reutilizadas sin autorización.

Ejercicios guiados

  1. ¿Qué método HTTP utiliza el siguiente mensaje de solicitud?

    POST /cgi-bin/receive.cgi HTTP/1.1
    Host: learning.lpi.org
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
    Accept: */*
    Content-Length: 27
    Content-Type: application/x-www-form-urlencoded
  2. Cuando un servidor HTTP aloja muchos sitios web, ¿cómo puede identificar para cuál es una solicitud?

  3. ¿Qué parámetro proporciona la cadena de consulta de la URL https://www.google.com/search?q=LPI?

  4. ¿Por qué la siguiente solicitud HTTP no es adecuada para el almacenamiento en caché?

    POST /cgi-bin/receive.cgi HTTP/1.1
    Host: learning.lpi.org
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
    Accept: */*
    Content-Length: 27
    Content-Type: application/x-www-form-urlencoded

Ejercicios de exploración

  1. ¿Cómo podría usar el navegador web para monitorear las solicitudes y respuestas hechas por una página HTML?

  2. Los servidores HTTP que proporcionan contenido estático generalmente asignan la ruta solicitada a un archivo en el sistema de archivos del servidor. ¿Qué sucede cuando la ruta de la solicitud apunta a un directorio?

  3. El contenido de los archivos enviados a través de HTTPS está protegido por cifrado, por lo que las computadoras entre el cliente y el servidor no pueden leerlos. A pesar de esto, ¿pueden estas computadoras intermedias identificar qué recurso ha solicitado el cliente al servidor?

Resumen

Esta lección cubre los conceptos básicos de HTTP, el protocolo principal utilizado por las aplicaciones cliente para solicitar recursos de los servidores web. La lección abarca los siguientes conceptos:

  • Solicitar mensajes, campos de encabezado y métodos.

  • Códigos de estado de respuesta.

  • Cómo los servidores HTTP generan respuestas.

  • Funciones HTTP útiles para el almacenamiento en caché y la gestión de sesiones.

Respuestas a los ejercicios guiados

  1. ¿Qué método HTTP utiliza el siguiente mensaje de solicitud?

    POST /cgi-bin/receive.cgi HTTP/1.1
    Host: learning.lpi.org
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
    Accept: */*
    Content-Length: 27
    Content-Type: application/x-www-form-urlencoded

    El método POST.

  2. Cuando un servidor HTTP aloja muchos sitios web, ¿cómo puede identificar para cuál es una solicitud?

    El campo Host en el encabezado de la solicitud proporciona el sitio web de destino.

  3. ¿Qué parámetro proporciona la cadena de consulta de la URL https://www.google.com/search?q=LPI?

    El parámetro denominado q con el valor LPI.

  4. ¿Por qué la siguiente solicitud HTTP no es adecuada para el almacenamiento en caché?

    POST /cgi-bin/receive.cgi HTTP/1.1
    Host: learning.lpi.org
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0
    Accept: */*
    Content-Length: 27
    Content-Type: application/x-www-form-urlencoded

    Debido a que las solicitudes realizadas con el método POST implican una operación de escritura en el servidor, no deben almacenarse en caché.

Respuestas a los ejercicios de exploración

  1. ¿Cómo podría usar el navegador web para monitorear las solicitudes y respuestas hechas por una página HTML?

    Todos los navegadores populares ofrecen herramientas de desarrollo que, entre otras cosas, pueden mostrar todas las transacciones de red que se han realizado en la página actual.

  2. Los servidores HTTP que proporcionan contenido estático generalmente asignan la ruta solicitada a un archivo en el sistema de archivos del servidor. ¿Qué sucede cuando la ruta de la solicitud apunta a un directorio?

    Depende de cómo esté configurado el servidor. De forma predeterminada, la mayoría de los servidores HTTP buscan un archivo llamado index.html (u otro nombre predefinido) en ese mismo directorio y lo envían como respuesta. Si el archivo no está allí, el servidor emite una respuesta 404 Not Found.

  3. El contenido de los archivos enviados a través de HTTPS está protegido por cifrado, por lo que las computadoras entre el cliente y el servidor no pueden leerlos. A pesar de esto, ¿pueden estas computadoras intermedias identificar qué recurso ha solicitado el cliente al servidor?

    No, porque los encabezados HTTP de solicitud y respuesta también están encriptados por TLS.

Linux Professional Insitute Inc. Todos los derechos reservados. Visite el sitio web de Learning Materials: https://learning.lpi.org
Este trabajo está registrado bajo la Licencia Internacional Creative Commons Attribution-NonCommercial-NoDerivatives 4.0

Siguiente lección

032.1 Anatomía del documento HTML (032.1 Lección 1)

Leer la próxima lección

Linux Professional Insitute Inc. Todos los derechos reservados. Visite el sitio web de Learning Materials: https://learning.lpi.org
Este trabajo está registrado bajo la Licencia Internacional Creative Commons Attribution-NonCommercial-NoDerivatives 4.0

LPI es una organización sin fines de lucro.

© 2022 Linux Professional Institute (LPI) es la organización global de certificación y apoyo académico para profesionales de código abierto. Con más de 200,000 titulares de certificación, es el primer y más grande organismo de certificación no comercial del mundo para Linux y Open Source. LPI cuenta con profesionales certificados en más de 180 países, realiza exámenes en varios idiomas y tiene cientos de socios de capacitación.

Nuestro propósito es hacer que las oportunidades económicas y creativas estén disponibles para todos, haciendo que el conocimiento de código abierto y la certificación sea universalmente accesible.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Contáctenos
  • Política de privacidad y cookies

¿Detecta un error o desea ayudar a mejorar esta página? Por favor háznoslo saber.

© 1999–2022 The Linux Professional Institute Inc. Todos los derechos reservados.