Http

http
Nombre Protocolo de Transferencia de Hipertexto
Nivel (según el modelo OSI ) Aplicado
Familia TCP/IP
Creado en 1992
Puerto/ID 80/ TCP
Especificación RFC 124 , RFC 1945 , RFC 2616 , RFC 2617 , RFC 6266 , RFC 7230 , RFC 7240 , RFC 8446 .
Implementaciones principales (clientes) Navegadores web , por ejemplo, Internet Explorer , Mozilla Firefox , Opera , Google Chrome , Yandex Browser , Microsoft Edge , etc.
Implementaciones principales ( servidores ) Apache , IIS , nginx , servidor web de Google , etc.
 Archivos multimedia en Wikimedia Commons

HTTP ( Protocolo de  transferencia de hipertexto  - " protocolo de transferencia de hipertexto ") es un protocolo de transferencia de datos de capa de aplicación , originalmente en forma de documentos de hipertexto en formato HTML , actualmente se usa para transferir datos arbitrarios.

Propiedades básicas

La base de HTTP es la tecnología "cliente-servidor" , es decir, la existencia de:

HTTP es ahora omnipresente en la World Wide Web para recuperar información de sitios web . En 2006, el tráfico HTTP en América del Norte superó al de las redes P2P en un 46 %, del cual casi la mitad era transmisión de video y audio [ 1] .

HTTP también se utiliza como "transporte" para otros protocolos de capa de aplicación como SOAP , XML-RPC , WebDAV .

El principal objeto de manipulación en HTTP es el recurso al que apunta un URI (Uniform Resource Identifier) ​​en una solicitud de cliente. Normalmente, estos recursos son archivos almacenados en el servidor , pero pueden ser objetos lógicos o algo abstracto. Una característica del protocolo HTTP es la capacidad de especificar en la solicitud y la respuesta cómo se representa el mismo recurso mediante varios parámetros: formato , codificación , idioma, etc. (en particular, se usa el encabezado HTTP para esto ). Es gracias a la posibilidad de especificar cómo se codifica el mensaje que el cliente y el servidor pueden intercambiar datos binarios , aunque este protocolo es de texto.

HTTP es un protocolo de capa de aplicación ; sus contrapartes son FTP y SMTP . Los mensajes se intercambian según el esquema habitual de "solicitud-respuesta". HTTP utiliza URI globales para identificar recursos . A diferencia de muchos otros protocolos, HTTP no tiene estado. Esto significa que no se almacena ningún estado intermedio entre pares de solicitud-respuesta. Los componentes que utilizan HTTP pueden almacenar de forma independiente información de estado relacionada con solicitudes y respuestas recientes (p. ej., " cookies " en el lado del cliente, "sesiones" en el lado del servidor). El navegador que envía las solicitudes puede realizar un seguimiento de los retrasos en la respuesta. El servidor puede almacenar las direcciones IP y solicitar encabezados de clientes recientes. Sin embargo, el protocolo en sí mismo no está al tanto de las solicitudes y respuestas anteriores, no proporciona soporte estatal interno, no tiene tales requisitos.

La mayoría de los protocolos prevén el establecimiento de una sesión TCP durante la cual la autorización se produce una vez y se realizan otras acciones en el contexto de esta autorización. HTTP establece una sesión TCP separada para cada solicitud; Las versiones posteriores de HTTP permitieron realizar múltiples solicitudes en una sola sesión TCP, pero los navegadores generalmente solo solicitan la página y los objetos incluidos en ella (imágenes, estilos en cascada, etc.) y luego finalizan la sesión TCP inmediatamente. HTTP utiliza cookies para permitir el acceso autorizado (no anónimo) ; Además, este método de autorización le permite guardar la sesión incluso después de reiniciar el cliente y el servidor.

Al acceder a datos a través de FTP o protocolos de archivo, el tipo de archivo (más precisamente, el tipo de datos que contiene) está determinado por la extensión del nombre del archivo, lo que no siempre es conveniente. HTTP, antes de transmitir los datos en sí, transmite el encabezado Content-Type: type / subtype, que permite al cliente determinar sin ambigüedades cómo procesar los datos enviados. Esto es especialmente importante cuando se trabaja con scripts CGI , cuando la extensión del nombre del archivo no indica el tipo de datos enviados al cliente, sino la necesidad de ejecutar este archivo en el servidor y enviar los resultados del programa escrito en este archivo al cliente. (en este caso, el mismo archivo en función de los argumentos de la solicitud y sus propias consideraciones, puede generar respuestas de diferentes tipos, en el caso más simple, imágenes en diferentes formatos).

Además, HTTP permite que el cliente envíe parámetros al servidor, que se pasarán al script CGI que se está ejecutando. Para ello , se introdujeron formularios en HTML .

Estas características de HTTP hicieron posible la creación de motores de búsqueda (el primero de los cuales fue AltaVista , creado por DEC ), foros y tiendas de Internet. Así se comercializó Internet, aparecieron empresas cuyo principal campo de actividad era la provisión de acceso a Internet (proveedores) y la creación de sitios web.

Software

Todo el software para trabajar con el protocolo HTTP se divide en tres grandes categorías:

Para distinguir los servidores finales de los proxies , la documentación oficial utiliza el término servidor de origen .  Un mismo producto de software puede realizar simultáneamente las funciones de cliente, servidor o intermediario, según las tareas. Las especificaciones del protocolo HTTP detallan el comportamiento de cada uno de estos roles.

Clientes

El protocolo HTTP se diseñó originalmente para acceder a documentos de hipertexto en la World Wide Web. Por lo tanto, las principales implementaciones de los clientes son los navegadores (agentes de usuario). Para ver el contenido guardado de los sitios en una computadora sin conexión a Internet, se inventaron los navegadores fuera de línea . Cuando la conexión es inestable, se utilizan gestores de descargas para descargar archivos de gran tamaño ; le permiten descargar los archivos especificados en cualquier momento después de perder la conexión con el servidor web. Algunos atlas virtuales (como Google Earth y NASA World Wind ) también usan HTTP.

A menudo, los programas utilizan el protocolo HTTP para descargar actualizaciones.

En los motores de búsqueda de Internet se utiliza toda una gama de programas de robots . Entre ellos se encuentran las arañas web ( rastreadores ) que atraviesan hipervínculos, compilan una base de datos de recursos del servidor y almacenan su contenido para su posterior análisis.

Servidores de origen

Principales implementaciones: Apache , Internet Information Services (IIS), nginx , LiteSpeed ​​​​Web Server (LSWS), Google Web Server , lighttpd .

Servidores proxy

Implementaciones principales: Squid , UserGate , Multiproxy , Naviscope , nginx .

Estructura del mensaje HTTP

Cada mensaje HTTP consta de tres partes, que se envían en el orden indicado:

  1. Línea de inicio ( ing.  Línea de inicio ) - determina el tipo de mensaje;
  2. Encabezados (Encabezados en inglés  ): caracterizan el cuerpo del mensaje, los parámetros de transmisión y otra información;
  3. El cuerpo del mensaje ( English  Message Body ) - datos directos del mensaje. Debe estar separado de los encabezados por una línea vacía.

Se puede omitir el cuerpo del mensaje, pero la línea de inicio y el encabezado son elementos obligatorios. La excepción es la versión 0.9 del protocolo, donde el mensaje de solicitud contiene solo la línea de inicio y el mensaje de respuesta contiene solo el cuerpo del mensaje.

Para la versión 1.1 del protocolo, el mensaje de solicitud debe contener el encabezado Host .

Línea de salida

Las cadenas de inicio son diferentes para solicitud y respuesta. La cadena de consulta se ve así:

GET URI — para la versión de protocolo 0.9; Метод URI HTTP/Версия - para otras versiones.

Aquí:

Para solicitar una página para este artículo, el cliente debe pasar la cadena (solo se proporciona un encabezado):

OBTENER /wiki/HTTP HTTP/1.0 Anfitrión: es.wikipedia.org

La línea de inicio de la respuesta del servidor tiene el siguiente formato: HTTP/Версия КодСостояния Пояснение, donde:

Por ejemplo, la línea de inicio de la respuesta del servidor a una solicitud anterior podría verse así:

HTTP/1.0 200 Aceptar

Métodos

Método HTTP ( Método HTTP en inglés  ): una secuencia de cualquier carácter, excepto el control y los delimitadores, que indica la operación principal en el recurso. Por lo general, el método es una palabra corta en inglés escrita en letras mayúsculas. Tenga en cuenta que el nombre del método distingue entre mayúsculas y minúsculas.

El servidor puede usar cualquier método, no hay métodos obligatorios para el servidor o el cliente. Si el servidor no reconoce el método especificado por el cliente, debería devolver el estado 501(No implementado). Si el servidor conoce el método, pero no es aplicable a un recurso en particular, 405se devuelve un mensaje con un código (Método no permitido). En ambos casos, el servidor DEBERÍA incluir un encabezado Allowcon una lista de métodos admitidos en el mensaje de respuesta.

Además de los métodos GETy HEAD, a menudo se utiliza el método POST.

OPCIONES

Se utiliza para determinar las capacidades del servidor web o las opciones de conexión para un recurso en particular. En respuesta, el servidor DEBERÍA incluir un encabezado Allowcon una lista de métodos admitidos. El encabezado de la respuesta también puede incluir información sobre las extensiones admitidas.

Se supone que la solicitud del cliente puede contener un cuerpo de mensaje para indicar la información de su interés. El formato del cuerpo y el orden de trabajo con él no está definido actualmente; el servidor debería ignorarlo por ahora. La situación es similar con el cuerpo en la respuesta del servidor.

Para conocer las capacidades de todo el servidor, el cliente debe especificar un asterisco - " *" - en el URI. Las solicitudes " OPTIONS * HTTP/1.1" también se pueden usar para verificar el estado del servidor (similar a " ping ") y para probar si el servidor admite el protocolo HTTP versión 1.1.

El resultado de ejecutar este método no se almacena en caché .

OBTENER

Se utiliza para consultar el contenido del recurso especificado. GETTambién puede iniciar un proceso utilizando un método . En este caso, la información sobre el progreso del proceso debe incluirse en el cuerpo del mensaje de respuesta.

El cliente puede pasar parámetros de ejecución de solicitudes en el URI del recurso de destino después del ?carácter “ ”:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

De acuerdo con el estándar HTTP, las solicitudes de tipo GETse consideran idempotentes [2]

Además del método habitual GET, también existen

El orden de ejecución de dichas solicitudes se define por separado en las normas.

CABEZA

Similar al método GET, excepto que no hay cuerpo en la respuesta del servidor. La consulta HEADgeneralmente se usa para recuperar metadatos , verificar la existencia de un recurso ( validación de URL ) y ver si ha cambiado desde la última vez que se accedió.

Los encabezados de respuesta se pueden almacenar en caché. Si los metadatos del recurso no coinciden con la información correspondiente en la memoria caché, la copia del recurso se marca como obsoleta.

PUBLICAR

Se utiliza para pasar datos de usuario a un recurso determinado. Por ejemplo, en los blogs , los visitantes generalmente pueden ingresar sus comentarios en las publicaciones en un formulario HTML, luego de lo cual se envían al servidor mediante el método POST y los coloca en la página. En este caso, los datos transmitidos (en el ejemplo del blog, el texto del comentario) se incluyen en el cuerpo de la solicitud. De manera similar, utilizando el método POST, los archivos generalmente se cargan en el servidor.

A diferencia del método GET, el método POSTno se considera idempotente [2] , es decir, la repetición repetida de las mismas consultas POSTpuede arrojar resultados diferentes (por ejemplo, después de enviar cada comentario, aparecerá otra copia de este comentario).

Si el resultado de la ejecución es 200(Ok), el cuerpo de la respuesta debe incluir un mensaje sobre el resultado de la solicitud. Si se ha creado un recurso, el servidor DEBERÍA devolver una respuesta 201(Creado) con el URI del nuevo recurso en el archivo Location.

El mensaje de respuesta del servidor de ejecución de métodos POSTno se almacena en caché.

PONE

Se utiliza para descargar el contenido de la solicitud al URI especificado en la solicitud. Si un recurso no existe para el URI dado, el servidor lo crea y devuelve el estado 201(Creado). Si se ha cambiado el recurso, el servidor devuelve 200(Ok) o 204(Sin contenido). El servidor NO DEBE ignorar los encabezados no válidos Content-*enviados por el cliente junto con el mensaje. Si alguno de estos encabezados no se puede reconocer o no es válido en las condiciones actuales, se 501debe devolver un código de error (No implementado).

La diferencia fundamental entre los métodos POSTradica PUTen comprender la intención de los URI de recursos. El método POSTasume que el contenido transmitido por el cliente se procesará en el URI especificado. Al usar PUT, el cliente asume que el contenido que se carga coincide con el recurso en el URI dado.

Los mensajes de respuesta del servidor a un método PUTno se almacenan en caché.

PARCHE

Similar a PUT, pero solo se aplica a un fragmento de recurso.

ELIMINAR

Elimina el recurso especificado.

RASTREO

Devuelve la solicitud recibida para que el cliente pueda ver qué información agregan o modifican los servidores intermedios en la solicitud.

CONECTAR

Convierte la conexión de solicitud en un túnel TCP/IP transparente , normalmente para facilitar el establecimiento de una conexión SSL segura a través de un proxy no cifrado .

Códigos de estado

El código de estado es parte de la primera línea de la respuesta del servidor. Es un número entero de tres dígitos [3] . El primer dígito indica la clase de estado. El código de respuesta suele ir seguido de una frase explicativa separada por espacios en inglés, que explica a la persona el motivo de tal respuesta. Ejemplos:

201 Página web creada 403 Acceso permitido solo para usuarios registrados 507 Almacenamiento insuficiente

El cliente aprende del código de respuesta sobre los resultados de su solicitud y determina qué acciones tomar a continuación. El conjunto de códigos de estado es un estándar y se describen en los documentos RFC pertinentes . La introducción de nuevos códigos solo debe realizarse después de consultar con el IETF . Es posible que el cliente no conozca todos los códigos de estado, pero debe responder de acuerdo con la clase de código.

Actualmente hay cinco clases de códigos de estado

El código Clase Objetivo
1xx Informativo

(ing. informativo )

Información sobre el proceso de transferencia.

En HTTP/1.0, los mensajes con dichos códigos deben ignorarse.

En HTTP/1.1, el cliente debe estar preparado para aceptar esta clase de mensaje como una respuesta normal, pero no es necesario enviar nada al servidor.

Los mensajes del propio servidor contienen solo la línea de inicio de la respuesta y, si es necesario, algunos campos de encabezado específicos de la respuesta. Los servidores proxy deben enviar dichos mensajes más allá del servidor al cliente.

2xx Éxito

( Éxito en inglés )

Informar sobre los casos de aceptación y tramitación exitosa de la solicitud del cliente. Según el estado, el servidor aún puede enviar los encabezados y el cuerpo del mensaje.
3xx redirigir

(ing. Redirección )

Informa al cliente que se debe realizar otra solicitud (generalmente por un URI diferente) para completar con éxito la operación. De esta clase, cinco códigos 301, 302, y 303se refieren directamente a redireccionamientos (redirect). La dirección a la que el cliente debe realizar una solicitud la indica el servidor en el . Esto permite que se utilicen fragmentos en el URI de destino. 305307Location
4xx error del cliente

( Error de cliente en inglés )

Indicación de errores del lado del cliente. Cuando se utilizan todos los métodos excepto HEAD, el servidor debe devolver una explicación de hipertexto para el usuario en el cuerpo del mensaje.
5xx Error del Servidor

( Error del servidor en inglés )

Informar sobre casos de operación fallida por falla del servidor. Para todas las situaciones que no sean el uso del método HEAD, el servidor DEBE incluir una explicación en el cuerpo del mensaje que el cliente mostrará al usuario.

Títulos

Los encabezados HTTP son cadenas en un mensaje HTTP que contienen un par parámetro-valor separados por dos puntos .  El formato de los encabezados sigue el formato general de los encabezados de mensajes de red de texto ARPA (ver RFC 822 ). Los encabezados deben estar separados del cuerpo del mensaje por al menos una línea en blanco.

Ejemplos de encabezado:

Servidor: Apache/2.2.11 (Win32) PHP/5.3.0 Última modificación: sábado, 16 de enero de 2010 21:16:42 GMT Tipo de contenido: texto/simple; conjunto de caracteres = windows-1251 Idioma del contenido: es

En el ejemplo anterior, cada línea representa un encabezado. En este caso, lo que está antes de los dos puntos se llama el nombre ( English  name ), y lo que está después se llama el valor ( English  value ).

Todos los títulos se dividen en cuatro grupos principales:

  1. Encabezados generales ("Encabezados principales"): se pueden incluir en cualquier mensaje del cliente y del servidor;
  2. Encabezados de solicitud ("Encabezados de solicitud"): se utilizan solo en solicitudes de clientes;
  3. Encabezados de respuesta ("Encabezados de respuesta"): solo para respuestas del servidor;
  4. Encabezados de entidad ("Encabezados de la entidad"): acompañan a cada entidad del mensaje.

Este es el orden en el que se recomienda enviar los encabezados al destinatario.

Todos los encabezados necesarios para que HTTP funcione se describen en las RFC principales . Si no hay suficientes existentes, puede ingresar el suyo propio. Tradicionalmente, los nombres de tales encabezados adicionales tienen el prefijo " X-" para evitar conflictos de nombres con los que posiblemente ya existan. Por ejemplo, como en encabezados X-Powered-Byo X-Cache. Algunos desarrolladores usan sus propios prefijos personalizados. Ejemplos de estos encabezados son los Ms-Echo-Requestintroducidos Ms-Echo-Replypor Microsoft para la extensión WebDAV .

Cuerpo del mensaje

El cuerpo del mensaje HTTP ( message-body), si está presente, se usa para transmitir el cuerpo del objeto asociado con la solicitud o respuesta. El cuerpo del mensaje difiere del cuerpo del objeto ( entity-body) solo cuando se aplica una codificación de transmisión, como lo indica el campo de encabezado Transfer-Encoding.

cuerpo-mensaje = cuerpo-entidad | <entidad-cuerpo codificado según codificación de transferencia>

El campo Transfer-Encodingse utilizará para indicar cualquier codificación de transmisión aplicada por la aplicación para garantizar que el mensaje se transmita de forma segura y correcta. Un campo Transfer-Encoding es una propiedad de un mensaje, no un objeto, y por lo tanto cualquier aplicación puede agregarlo o eliminarlo en la cadena de solicitud/respuesta.

Las reglas que rigen la validez del cuerpo de un mensaje en un mensaje son diferentes para solicitudes y respuestas.

La presencia de un cuerpo de mensaje en una solicitud se indica agregando un campo de encabezado Content-Lengthoa los encabezados de la solicitud Transfer-Encoding. Un cuerpo de mensaje solo se puede agregar a una solicitud cuando el método de solicitud permite un cuerpo de objeto.

La inclusión o no del cuerpo del mensaje en el mensaje de respuesta depende tanto del método de solicitud como del código de estado de la respuesta. Todas las respuestas a una solicitud con un método HEADno deben incluir un cuerpo de mensaje, incluso si los campos de encabezado de objeto ( entity-header) están presentes para que parezca que el objeto está presente. Ninguna respuesta con códigos de estado 1xx(Informativo), 204(Sin contenido) y 304(No modificado) debe contener un cuerpo de mensaje. Todas las demás respuestas contienen un cuerpo de mensaje, incluso si es de longitud cero.

Ejemplos de diálogos HTTP

Solicitud GET regular

Solicitud del cliente:

OBTENER /wiki/ HTTP/1.1 página Anfitrión: es.wikipedia.org Agente de usuario: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Aceptar: texto/html Conexión: cerrar (línea vacía)

Respuesta del servidor:

HTTP/1.1 200 Aceptar Fecha: miércoles, 11 de febrero de 2009 11:20:59 GMT Servidor: Apache Desarrollado por X: PHP/5.2.4-2ubuntu5wm1 Última modificación: miércoles, 11 de febrero de 2009 11:20:59 GMT Idioma del contenido: es Tipo de contenido: texto/html; conjunto de caracteres = utf-8 Longitud del contenido: 1234 Conexión: cerrar (cadena vacía) (página solicitada en HTML )

La respuesta parece la misma 203. Lo que es importante: los datos solicitados directamente se separan de los encabezados HTTP mediante CR , LF , CR, LF.

Redirecciones

Supongamos que la empresa ficticia "Example Corp." hay un sitio principal en "http://example.com" y un dominio de alias "example.org" . El cliente envía una solicitud de la página "Acerca de" al dominio secundario (se omiten algunos encabezados):

OBTENER /acerca de.html HTTP/1.1 Anfitrión: ejemplo.org Agente de usuario: MyLonelyBrowser/5.0

Dado que el dominio "example.org" no es un dominio principal y la empresa no pretende utilizarlo para otros fines en el futuro, su servidor devolverá un código para una redirección permanente, indicando la LocationURL de destino en el encabezado:

HTTP/1.x 301 movido permanentemente Ubicación: http://example.com/about.html#contacts Fecha: jueves, 19 de febrero de 2009 11:08:01 GMT Servidor: Apache/2.2.4 Tipo de contenido: texto/html; conjunto de caracteres = windows-1251 Longitud del contenido: 110 (línea vacía) <html><body><a href="http://example.com/about.html#contacts">Haga clic aquí</a></body></html>

En el título Location, puede especificar fragmentos como en este ejemplo. El navegador no especificó un fragmento en la solicitud porque está interesado en el documento completo. Pero automáticamente desplazará la página al fragmento de "contactos" tan pronto como lo cargue. También se colocó un breve documento HTML en el cuerpo de la respuesta con un enlace que llevaría al visitante a la página de destino si el navegador no navegaba automáticamente hasta ella. El título Content-Typecontiene las características de esa explicación HTML en particular, no del documento que se encuentra en el URI de destino.

Digamos que la misma empresa "Example Corp." tiene varias oficinas regionales en todo el mundo. Y para cada agencia tienen un sitio web con un ccTLD correspondiente . La solicitud de página de inicio para el sitio principal "example.com" podría verse así:

OBTENER /HTTP/1.1 host: ejemplo.com Agente de usuario: MyLonelyBrowser/5.0 Aceptar: texto/html,aplicación/xhtml+xml,aplicación/xml;q=0.9,*/*;q=0.8 Aceptar-Idioma: ru,en-us;q=0.7,en;q=0.3 Aceptar juego de caracteres: windows-1251,utf-8;q=0.7,*;q=0.7

El servidor tuvo en cuenta el encabezado Accept-Languagey formó una respuesta con una redirección temporal al servidor ruso "example.ru" , indicando su dirección en el encabezado Location:

HTTP/1.x 302 encontrado Ubicación: http://ejemplo.ru/ Control de caché: privado Fecha: jueves, 19 de febrero de 2009 11:08:01 GMT Servidor: Apache/2.2.6 Tipo de contenido: texto/html; conjunto de caracteres = windows-1251 Longitud del contenido: 82 (línea vacía) <html><body><a href="http://example.ru">Corporación Ejemplo</a></body></html>

Preste atención al encabezado Cache-Control: el valor "privado" le dice al resto de los servidores (principalmente servidores proxy) que la respuesta solo se puede almacenar en caché en el lado del cliente. De lo contrario, es posible que los siguientes visitantes de otros países vayan siempre a una representación diferente.

303Los códigos de respuesta (Ver Otro) y 307(Redirección Temporal) también se utilizan para la redirección .

Descarga de currículum y fragmentos

Digamos que una organización ficticia ofrece descargar un video de la conferencia pasada del sitio web en: "http://example.org/conf-2009.avi" - aproximadamente 160 MB de tamaño . Consideremos cómo se reanuda este archivo en caso de falla y cómo el administrador de descargas organizaría la descarga de múltiples subprocesos de varios fragmentos.

En ambos casos, los clientes realizarán su primera solicitud así:

OBTENER /conf-2009.avi HTTP/1.0 Anfitrión: ejemplo.org Aceptar: */* Agente de usuario: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Referencia: http://example.org/

El título Refererindica que el archivo fue solicitado desde la página principal del sitio. Los administradores de descargas generalmente también lo especifican para emular la transición desde la página del sitio. Sin él, el servidor puede responder 403(Acceso prohibido) si no se permiten solicitudes de otros sitios. En nuestro caso, el servidor devolvió una respuesta exitosa:

HTTP/1.1 200 Aceptar Fecha: jueves, 19 de febrero de 2009 12:27:04 GMT Servidor: Apache/2.2.3 Última modificación: miércoles, 18 de junio de 2003 16:05:58 GMT Etiqueta electrónica: "56d-9989200-1132c580" Tipo de contenido: video/x-msvideo Longitud del contenido: 160993792 Rangos de aceptación: bytes Conexión: cerrar (cadena vacía) (contenido binario de todo el archivo)

El encabezado Accept-Rangesinforma al cliente que puede solicitar fragmentos del servidor especificando sus desplazamientos desde el principio del archivo en bytes. Si falta este encabezado, entonces el cliente PUEDE advertir al usuario que lo más probable es que el archivo no se descargue.

Según el valor del encabezado Content-Length, el administrador de descargas dividirá todo el volumen en fragmentos iguales y los solicitará por separado, organizando varios flujos. Si el servidor no especifica un tamaño, entonces el cliente no podrá implementar descargas paralelas, pero aún podrá descargar el archivo hasta que el servidor responda 416(Rango solicitado no satisfactorio).

Digamos que en el megabyte 84 se interrumpió la conexión a Internet y se detuvo el proceso de descarga. Cuando se restableció la conexión a Internet, el administrador de descargas envió automáticamente una nueva solicitud al servidor, pero con una instrucción para devolver el contenido del megabyte 84:

OBTENER /conf-2009.avi HTTP/1.0 Anfitrión: ejemplo.org Aceptar: */* Agente de usuario: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Rango: bytes=88080384- Referencia: http://example.org/

El servidor no está obligado a recordar qué y de quién se realizaron solicitudes antes, y por lo tanto, el cliente insertó el encabezado nuevamente Referer, como si fuera su primera solicitud. El valor del encabezado especificado Rangele dice al servidor: "Entregue el contenido desde el byte 88080384 hasta el final". En este sentido, el servidor devolverá una respuesta:

HTTP/1.1 206 Contenido parcial Fecha: jueves, 19 de febrero de 2009 12:27:08 GMT Servidor: Apache/2.2.3 Última modificación: miércoles, 18 de junio de 2003 16:05:58 GMT Etiqueta electrónica: "56d-9989200-1132c580" Rangos de aceptación: bytes Rango de contenido: bytes 88080384-160993791/160993792 Longitud del contenido: 72913408 Conexión: cerrar Tipo de contenido: video/x-msvideo (cadena vacía) (contenido binario del megabyte 84)

El encabezado Accept-Rangesya no es necesario aquí, ya que el cliente ya conoce esta capacidad del servidor. El hecho de que un fragmento está siendo transmitido es conocido por el cliente por el código 206(Contenido Parcial). El encabezado Content-Rangecontiene información sobre este fragmento: los números del byte inicial y final, y después de la barra inclinada, el tamaño total del archivo completo en bytes. Preste atención al encabezado Content-Length : indica el tamaño del cuerpo del mensaje, es decir, el fragmento transmitido. Si el servidor devuelve varios fragmentos, Content-Lengthcontendrá su volumen total.

Ahora volvamos al administrador de descargas. Conociendo el tamaño total del archivo "conf-2009.avi" , el programa lo dividió en 10 secciones iguales.

El administrador inicial se cargará en la primera solicitud, interrumpiendo la conexión tan pronto como llegue al comienzo de la segunda. El resto se solicitará por separado. Por ejemplo, la cuarta sección se solicitaría con los siguientes encabezados (se omiten algunos encabezados; consulte el ejemplo completo anterior):

OBTENER /conf-2009.avi HTTP/1.0 Rango: bytes=64397516-80496894

La respuesta del servidor en este caso será la siguiente (se omiten parte de los encabezados; consulte el ejemplo completo anterior):

HTTP/1.1 206 Contenido parcial Rangos de aceptación: bytes Rango de contenido: bytes 64397516-80496894/160993792 Longitud del contenido: 16099379 (cadena vacía) (cuarta parte de contenido binario)

Si dicha solicitud se envía a un servidor que no admite fragmentos, devolverá una respuesta estándar 200(OK) como se muestra al principio, pero sin el encabezado Accept-Ranges.

Consulte también GET parcial , rangos de bytes , respuesta 206 , respuesta 416 .

Mecanismos básicos del protocolo

GET parciales

HTTP le permite solicitar no todo el contenido del recurso a la vez, sino solo el fragmento especificado. Tales solicitudes se denominan parciales GET; la capacidad de ejecutarlos es opcional (pero deseable) para los servidores. Los parciales se GETutilizan principalmente para reanudar archivos y descargas paralelas rápidas en varios subprocesos. Algunos programas descargan el encabezado del archivo, muestran la estructura interna al usuario y luego solicitan fragmentos con los elementos de archivo especificados.

Para recibir un fragmento, el cliente envía una solicitud al servidor con un encabezado Rangeque especifica los rangos de bytes requeridos en él . Si el servidor no entiende las solicitudes parciales (ignora el encabezado Range), devolverá todo el contenido con el estado 200, al igual que con un archivo normal GET. En caso de finalización exitosa, el servidor devuelve una 200respuesta con estado 206(Contenido parcial) en lugar de un código, incluyendo el encabezado en la respuesta Content-Range. Los propios fragmentos se pueden pasar de dos maneras:

GET condicionales

El método GETcambia a "condicional GET" si el mensaje de solicitud incluye un campo de encabezado If-Modified-Since. En respuesta a "condicional GET", el cuerpo del recurso solicitado solo se envía si ha cambiado desde la fecha especificada en el encabezado If-Modified-Since. El algoritmo para determinar esto incluye los siguientes casos:

El uso del método "GET condicional" tiene como objetivo descargar la red, ya que permite no transmitir información redundante a través de la red.

Negociación de contenido

La negociación de contenido es un  mecanismo para determinar automáticamente el recurso requerido en presencia de varias versiones diferentes de un documento. Los temas de negociación pueden ser no solo recursos del servidor, sino también páginas devueltas con mensajes de error ( 403 , 404 , etc.).

Hay dos tipos principales de acuerdos:

Ambos tipos se pueden utilizar al mismo tiempo o cada uno de ellos por separado.

La especificación del protocolo principal ( RFC 2616 ) también destaca la llamada negociación transparente como la combinación preferida de ambos tipos .  Este último mecanismo no debe confundirse con la tecnología independiente de negociación de contenido transparente (TCN) , que no forma parte del protocolo HTTP pero se puede utilizar con él. Ambos tienen una diferencia significativa en el principio de funcionamiento y el significado mismo de la palabra "transparente" (transparente). En la especificación HTTP, la transparencia significa que el proceso es invisible para el cliente y el servidor, y en la tecnología TCN, la transparencia significa la disponibilidad de una lista completa de opciones de recursos para todos los participantes en el proceso de entrega de datos.

Administrado por servidor

Si hay varias versiones de un recurso, el servidor puede analizar los encabezados de solicitud del cliente para devolver lo que cree que es el mejor. Los encabezados Accept, Accept-Charset, y Accept-Encodingse analizan principalmente . Es conveniente que el servidor incluya una cabecera en la respuesta indicando los parámetros por los que se distingue el contenido de la URI solicitada. Accept-LanguagesUser-AgentVary

La ubicación geográfica del cliente se puede determinar a partir de la dirección IP remota . Esto es posible debido al hecho de que las direcciones IP, como los nombres de dominio , están registradas a nombre de una persona u organización específica. Al registrarse, especifica la región en la que se utilizará el espacio de direcciones deseado. Estos datos están disponibles públicamente, y en Internet puede encontrar las correspondientes bases de datos distribuidas gratuitamente y módulos de software listos para usar para trabajar con ellos (debe centrarse en las palabras clave "Geo IP").

Cabe recordar que este método es capaz de determinar la ubicación con la máxima precisión de la ciudad (a partir de aquí se determina el país). En este caso, la información es relevante solo en el momento del registro del espacio de direcciones. Por ejemplo, si un proveedor de Moscú registra un rango de direcciones que indican Moscú y comienza a brindar acceso a los clientes de los suburbios más cercanos, entonces sus suscriptores pueden observar en algunos sitios que son de Moscú, y no de Krasnogorsk o Dzerzhinsky .

La negociación administrada por el servidor tiene varias desventajas:

  • El servidor solo asume qué opción es la más preferible para el usuario final, pero no puede saber exactamente qué se necesita en este momento (por ejemplo, una versión en ruso o inglés).
  • Hay muchos encabezados de grupo Aceptar, pero pocos recursos con múltiples opciones. Debido a esto, el equipo está sobrecargado.
  • La memoria caché compartida tiene una capacidad limitada para emitir la misma respuesta a solicitudes idénticas de diferentes usuarios.
  • Pasar los encabezados de Aceptar también puede revelar cierta información sobre sus preferencias, como los idiomas utilizados, el navegador, la codificación.
Administrado por el cliente

En este caso, el tipo de contenido se determina solo en el lado del cliente. Para ello, el servidor devuelve en respuesta con un código de estado 300(Opciones Múltiples) o 406(No Aceptable) una lista de opciones, entre las cuales el usuario selecciona la adecuada. La negociación administrada por el cliente funciona bien cuando el contenido difiere en las formas más comunes (como el idioma y la codificación) y se usa una memoria caché pública.

La principal desventaja es la sobrecarga, ya que debe realizar una solicitud adicional para obtener el contenido deseado.

Negociación transparente

Esta negociación es completamente transparente para el cliente y el servidor. En este caso, se utiliza un caché compartido, que contiene una lista de opciones, como para una negociación administrada por el cliente. Si la memoria caché comprende todas estas opciones, toma la decisión por sí misma, como en una negociación administrada por el servidor. Esto reduce la carga en el servidor de origen y elimina la solicitud adicional del cliente.

La especificación principal de HTTP no describe en detalle el mecanismo de negociación transparente.

Contenido múltiple

El protocolo HTTP admite la transferencia de múltiples entidades dentro de un solo mensaje. Además, las entidades se pueden transferir no solo como una secuencia de un solo nivel, sino también como una jerarquía con elementos anidados entre sí. Los tipos de medios se utilizan para indicar contenido múltiple multipart/*. El trabajo con tales tipos se lleva a cabo de acuerdo con las reglas generales descritas en RFC 2046 (a menos que se defina lo contrario por un tipo de medio específico). Si el receptor no sabe cómo trabajar con el tipo, lo trata de la misma manera que multipart/mixed.

El parámetro de límite significa el separador entre los diferentes tipos de mensajes que se envían. Por ejemplo, el parámetro DestAddress pasado desde el formulario pasa el valor de la dirección de correo electrónico y el elemento AttachedFile1 que le sigue envía el contenido binario de la imagen .jpg.

En el lado del servidor, los mensajes con contenido múltiple pueden enviarse en respuesta a mensajes parcialesGET cuando se solicitan múltiples fragmentos de recursos. En este caso, se utiliza el tipo de medio multipart/byteranges.

En el lado del cliente, al enviar un formulario HTMLPOST , el archivo . Un ejemplo típico son las páginas de envío de correo electrónico con archivos adjuntos. Al enviar una carta de este tipo, el navegador genera un mensaje del tipo multipart/form-data, integrando en él como partes separadas ingresadas por el usuario, el asunto de la carta, la dirección del destinatario, el texto mismo y los archivos adjuntos:

POST /enviar-mensaje.html HTTP/1.1 Anfitrión: correo.ejemplo.com Referencia: http://mail.example.com/send-message.html Agente de usuario: BrowserForDummies/4.67b Tipo de contenido: multipart/form-data; límite="Asrf456BGe4h" Content-Length: (longitud total, incluidos los encabezados secundarios) Conexión: mantener vivo Mantener vivo: 300 (cadena vacía) (preámbulo faltante) --Asrf456BGe4h Contenido-Disposición: formulario-datos; name="Dirección de destino" (línea vacía) [email protected] --Asrf456BGe4h Contenido-Disposición: formulario-datos; nombre="Título del mensaje" (línea vacía) me molesta --Asrf456BGe4h Contenido-Disposición: formulario-datos; nombre="Texto del mensaje" (línea vacía) ¡Hola Vasily! Tu león mascota que dejaste atrás la semana pasada, destrozó todo mi sofá. ¡Por favor, recójalo pronto! Se adjuntan dos imágenes de las secuelas. --Asrf456BGe4h Contenido-Disposición: formulario-datos; nombre="ArchivoAnexado1"; filename="foto-de-horror-1.jpg" Tipo de contenido: imagen/jpeg (cadena vacía) (contenido binario de la primera foto) --Asrf456BGe4h Contenido-Disposición: formulario-datos; nombre="ArchivoAnexo2"; filename="foto-de-horror-2.jpg" Tipo de contenido: imagen/jpeg (cadena vacía) (contenido binario de la segunda foto) --Asrf456BGe4h-- (epílogo faltante)

En el ejemplo de los encabezados , el Content-Dispositionparámetro namecoincide con el atributo nameen las etiquetas HTML <INPUT>y <TEXTAREA>. El parámetro filenamees igual al nombre del archivo original en la computadora del usuario. Consulte RFC 1867 para obtener más información sobre la generación de formularios HTML y archivos adjuntos .

Historial de desarrollo

HTTP/0.9 HTTP fue propuesto en marzo de 1991 por Tim Berners-Lee , entonces en el CERN , como un mecanismo para acceder a documentos en Internet y facilitar la navegación mediante el uso de hipertexto . La primera versión del protocolo HTTP/0.9 se publicó por primera vez en enero de 1992 (aunque la implementación se remonta a 1990 ). La especificación del protocolo condujo a una simplificación de las reglas para la interacción entre los clientes y servidores HTTP, así como a una clara separación de funciones entre estos dos componentes. Se documentaron las principales disposiciones sintácticas y semánticas . HTTP/1.0 En mayo de 1996, se emitió el RFC 1945 para la implementación práctica de HTTP , proporcionando la base para la implementación de la mayoría de los componentes de HTTP/1.0. HTTP/1.1 Versión moderna del protocolo; adoptado en junio de 1999 [4] . Lo nuevo en esta versión fue un modo de "conexión persistente": una conexión TCP puede permanecer abierta después de que se haya enviado una respuesta a una solicitud, lo que permite enviar múltiples solicitudes en la misma conexión. Ahora se requiere que el cliente envíe información sobre el nombre del host al que accede, lo que ha hecho posible una organización más fácil del alojamiento compartido . HTTP/2 El 11 de febrero de 2015 se publicaron las versiones finales del borrador de la próxima versión del protocolo. A diferencia de las versiones anteriores, el protocolo HTTP/2 es binario . Las características clave incluyen la multiplexación de solicitudes, la priorización de solicitudes, la compresión de encabezados, la carga de varios elementos en paralelo a través de una única conexión TCP , la compatibilidad con notificaciones push proactivas del lado del servidor [5] . HTTP/3 HTTP/3  es un sucesor propuesto de HTTP/2 [6] [7] que ya está en uso en la Web basado en UDP en lugar de TCP como protocolo de transporte. Al igual que HTTP/2, no desaprueba las versiones principales anteriores del protocolo. La compatibilidad con HTTP/3 se agregó a Cloudflare y Google Chrome en septiembre de 2019 [8] [9] y se puede habilitar en versiones estables de Chrome y Firefox [10] .

Véase también

Notas

  1. ↑ El volumen de tráfico HTTP superó a P2P por primera vez Archivado el 22 de diciembre de 2007 en Wayback Machine // Compulenta, 22 de junio de 2007 ( documento blanco de Ellacoya Networks Archivado el 22 de junio de 2007 en Wayback Machine ).
  2. ↑ 1 2 HTTP/1.1: Definiciones de métodos  (inglés)  (enlace descendente) . Archivado desde el original el 23 de junio de 2012.
  3. ↑ Consulte la primera oración de la sección " 6.1.1 Código de estado y frase de motivo " en RFC 2068. También hay una declaración de BNF aumentada en la página 40.) " extension-code = 3DIGIT" para códigos de extensión.
  4. ↑ La especificación HTTP/1.1 se publicó por primera vez en enero de 1997 RFC 2068 ; en la versión moderna de RFC 2616 , se han corregido errores tipográficos, la terminología y el formato se han mejorado en algunos lugares. También aclaró el comportamiento aceptable del cliente (navegador), servidor y servidores proxy en algunas situaciones cuestionables. Es decir, la versión 1.1 apareció después de todo en 1997.
  5. ↑ Borrador de HTTP/2 . Consultado el 25 de febrero de 2015. Archivado desde el original el 20 de febrero de 2015.
  6. ↑ Bishop, Mike Protocolo de transferencia de hipertexto versión 3 (HTTP/3  ) . tools.ietf.org (9 de julio de 2019). Consultado el 16 de agosto de 2019. Archivado desde el original el 31 de agosto de 2019.
  7. ↑ Cimpanu, Catalín . HTTP-over-QUIC será renombrado HTTP/3 | ZDNet  (inglés) , ZDNet . Archivado desde el original el 13 de noviembre de 2018. Consultado el 10 de agosto de 2020.
  8. ↑ Cimpanu, Catalin Cloudflare, Google Chrome y Firefox agregan compatibilidad con HTTP/3 . ZDNet (26 de septiembre de 2019). Consultado el 27 de septiembre de 2019. Archivado desde el original el 26 de septiembre de 2019.
  9. ↑ HTTP/3: el pasado, el presente y el  futuro . El blog de Cloudflare (26 de septiembre de 2019). Consultado el 30 de octubre de 2019. Archivado desde el original el 26 de septiembre de 2019.
  10. ↑ Firefox Nightly es compatible con HTTP 3 - General - Comunidad de Cloudflare (19 de noviembre de 2019). Consultado el 23 de enero de 2020. Archivado desde el original el 6 de junio de 2020.

Enlaces

 esquemas URI
Oficial
no oficial
 web semántica
Lo esencial
Subsecciones
Aplicaciones
Temas relacionados
Estándares
  • Historia : HTML semántico simple y antiguo
  • DAML+ACEITE
 http
Conceptos generales
Métodos
Títulos
Códigos de estado