Hogar › Teléfono › Qué se transmite durante las solicitudes http. Breve descripción del protocolo HTTP. Recursos y métodos

Qué se transmite durante las solicitudes http. Breve descripción del protocolo HTTP. Recursos y métodos

Supongamos que sí. Puede determinar usted mismo el ancho y la compatibilidad entre navegadores. También puede desplazarse hacia la derecha seleccionando texto.

En general, ocultar el pergamino es una mala idea.

HTML, cuerpo (desbordamiento: oculto; altura: 100%; tamaño de caja: cuadro de borde; margen: 0;) cuerpo (desbordamiento-y: desplazamiento; ancho: calc(100% + 20px); relleno: 8px;)

Hola. ¿Es posible eliminarlo u ocultarlo en el sitio web? metodos css o javascript desplazamiento vertical, pero ¿para que el desplazamiento funcione como de costumbre? Por ejemplo, puedes aplicar overflow-y:hidden al cuerpo, pero naturalmente el desplazamiento deja de funcionar.

Hola. ¿Es posible eliminar u ocultar el desplazamiento vertical en un sitio web utilizando métodos CSS o javascript, pero que el desplazamiento siga funcionando como de costumbre? Por ejemplo, puedes aplicar overflow-y:hidden al cuerpo, pero naturalmente el desplazamiento deja de funcionar.

Opción sin usar calc posicionamiento fijo. Resuelve un problema con el desplazamiento horizontal al seleccionar.

Html (desbordamiento: oculto;) cuerpo (posición: fija; izquierda: 0; arriba: 0; derecha: -30px; abajo: 0; relleno: 8px; desbordamiento-y: desplazamiento;)

Otra opción para los cromos:

::-webkit-barra de desplazamiento (ancho: 0;)

Protocolo de transferencia de hipertexto (HTTP)- este es el protocolo alto nivel(es decir, la capa de aplicación), proporcionando la velocidad de transferencia de datos necesaria para los sistemas de información hipermedia distribuidos. HTTP es utilizado por el proyecto mundial. Amplia red desde 1990.

Práctico sistemas de información requieren más que búsqueda, modificación y anotación de datos primitivos. HTTP/1.0 proporciona un conjunto abierto de métodos que se pueden utilizar para especificar los propósitos de una solicitud. Se basan en una disciplina de referencia, donde la Identificador universal Recursos (Identificador Universal de Recursos - URI), como ubicación (URL) o nombre (URN). El formato del mensaje es similar al correo de Internet o a las extensiones multipropósito de correo de Internet (MIME).

HTTP/1.0 también se utiliza para comunicaciones entre varios navegadores de usuarios y puertas de enlace que brindan acceso hipermedia a protocolos de Internet existentes como SMTP, NNTP, FTP, Gopher y WAIS. HTTP/1.0 está diseñado para permitir que dichas puertas de enlace servidores proxy, sin pérdida alguna, transmite datos utilizando los protocolos mencionados de versiones anteriores.

Estructura General

HTTP se basa en un paradigma de solicitud/respuesta. El programa solicitante (generalmente llamado cliente) establece una conexión con el programa de servicio receptor (generalmente llamado servidor) y envía una solicitud al servidor en siguiente formulario: método de solicitud, URI, versión del protocolo, seguido de un mensaje tipo MIME que contiene información de control solicitud, información del cliente y tal vez el cuerpo del mensaje. El servidor responde con un mensaje que contiene una cadena de estado (incluida la versión del protocolo y un código de estado de éxito o error), seguido de un mensaje similar a MIME que incluye información sobre el servidor, metainformación sobre el contenido de la respuesta y quizás la respuesta. cuerpo mismo. Cabe señalar que un programa puede ser cliente y servidor al mismo tiempo. El uso de estos términos en este texto se refiere únicamente al rol desempeñado por el programa durante esa sesión de comunicación en particular, y no a funciones generales programas.

En Internet las comunicaciones suelen basarse en protocolos TCP/IP. Para WWW, el número de puerto predeterminado es TCP 80, pero también se pueden usar otros números de puerto; esto no excluye la posibilidad de usar HTTP como protocolo de nivel superior.

Para la mayoría de las aplicaciones, el cliente abre una sesión para cada solicitud y el servidor la cierra una vez que se ha completado la respuesta a la solicitud. Sin embargo, esta no es una característica del protocolo. Tanto el cliente como el servidor deben poder cerrar la sesión de comunicación, por ejemplo, como resultado de alguna acción del usuario. En cualquier caso, una desconexión iniciada por cualquiera de las partes finaliza la solicitud actual, independientemente de su estado.

Conceptos generales

Una solicitud es un mensaje enviado por un cliente a un servidor.
La primera línea de este mensaje incluye el método que se aplicará al recurso solicitado, el identificador del recurso y la versión del protocolo que se utilizará. Para compatibilidad con el protocolo HTTP/0.9, existen dos formatos de solicitud HTTP:

Consulta = Consulta simple | Solicitud completa Solicitud simple = "GET" SP URI solicitada CRLF Solicitud completa = Estado de línea *(Encabezado-general | Encabezado de solicitud | Encabezado de contenido) CRLF [Contenido de solicitud]

Si un servidor HTTP/1.0 recibe una solicitud simple, debe responder con una respuesta simple HTTP/0.9. Un cliente HTTP/1.0 capaz de procesar una respuesta completa nunca debería enviar una solicitud simple.

Estado de la línea

La línea de Estado comienza con una línea con el nombre del método, seguida del URI de solicitud y la versión del protocolo que se utiliza. La línea de estado termina con caracteres CRLF. Los elementos de línea están separados por espacios (SP). Los caracteres LF y CR no están permitidos en la línea de estado, con la excepción de la secuencia CRLF de cierre.

Estado de cadena = Método SP Solicitud URI Versión de SP-HTTP CRLF

Cabe señalar que la diferencia entre la línea de estado de solicitud completa y la línea de estado Solicitud sencilla consiste en la presencia del campo Versión HTTP.

Método

El campo Método especifica el método que se debe aplicar al recurso identificado por el URI de solicitud. Los nombres de los métodos distinguen entre mayúsculas y minúsculas. La lista existente de métodos se puede ampliar.

La lista de métodos permitidos por un recurso en particular se puede especificar en el campo Título-Contenido de "Puntos". Sin embargo, el servidor siempre notifica al cliente mediante un código de estado de respuesta si la aplicación está permitida. este método para el recurso especificado, ya que la admisibilidad de utilizar varios metodos puede cambiar dinámicamente. Si el servidor conoce un método determinado, pero no está permitido para el recurso especificado, el servidor DEBE devolver un código de estado de "Método 405 no permitido" y un código de estado de "501 No implementado" si el método no se conoce. o no soportado por el servidor dado. Los métodos HTTP/1.0 comunes se describen a continuación.

CONSEGUIR

El método GET se utiliza para recuperar cualquier información identificada por el URI de solicitud. Si el URI de solicitud se refiere a un proceso que produce datos, la respuesta serán los datos generados por ese proceso, no el código del proceso en sí (a menos que sea el resultado del proceso).

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

Si el código de estado de respuesta de la solicitud no es "200 OK" o la fecha especificada en el campo de encabezado "If-Modified-Since" es incorrecta, la respuesta será idéntica a la respuesta a una solicitud GET normal.
Si el recurso ha cambiado desde la fecha especificada, la respuesta también será idéntica a la respuesta a una solicitud GET normal.
Si el recurso no se ha modificado desde la fecha especificada, el servidor devolverá un código de estado "304 No modificado".

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

CABEZA

El método HEAD es similar al método GET, excepto que el servidor no devuelve un cuerpo de respuesta en la respuesta. La metainformación contenida en los encabezados HTTP de una respuesta a una solicitud HEAD debe ser idéntica a la información contenida en los encabezados HTTP de una respuesta a una solicitud GET. Este método se puede utilizar para obtener metainformación sobre un recurso sin transmitir el recurso en sí a través de la red. El método "HEAD condicional", similar al GET condicional, no está definido.

CORREO

método POST se utiliza para solicitar al servidor que acepte la información incluida en la solicitud como subordinada al recurso especificado en la línea de estado en el campo URI de solicitud. El método POST fue diseñado para permitir a uno método general para las siguientes funciones:

Resumen de recursos existentes
Agregar mensajes a grupos de noticias, listas de correo o grupos de artículos similares
Entrega de bloques de datos a procesos que procesan datos.
Ampliar bases de datos mediante una operación de adición

La función real realizada por el método POST la determina el servidor y generalmente depende del URI de solicitud. La información agregada se trata como subordinada al URI especificado en el mismo sentido que un archivo está subordinado al directorio en el que se encuentra. nuevo articulo subordinada al grupo de noticias al que se agrega, la entrada está subordinada a la base de datos.

El cliente puede proponer un URI para identificar el nuevo recurso incluyendo un encabezado "URI" en la solicitud. Sin embargo, el servidor debe tratar este URI solo como una sugerencia y puede almacenar el cuerpo de la solicitud bajo un URI diferente o ningún URI en absoluto.

Si se creó un nuevo recurso como resultado del procesamiento de una solicitud POST, la respuesta debe tener un código de estado "201 Creado" y contener el URI del nuevo recurso.

PONER

El método PUT solicita al servidor que almacene el cuerpo de la solicitud en un URI igual al URI de la solicitud. Si el URI de solicitud hace referencia a un recurso ya existente, el cuerpo de la solicitud debe tratarse como una versión modificada de ese recurso. Si el recurso al que hace referencia el URI de solicitud no existe y el URI proporcionado puede considerarse una descripción de un nuevo recurso, el servidor puede crear un recurso con el URI dado. Si se ha creado un nuevo recurso, el servidor debe informar al cliente solicitante mediante una respuesta con el código de estado "201 Creado". Si se ha modificado un recurso existente, se debe enviar una respuesta "200 OK" para informar al cliente que la operación se completó correctamente. Si no se puede crear o modificar un recurso con el URI especificado, se debe enviar un mensaje de error apropiado.

La diferencia fundamental entre los métodos POST y PUT es el significado diferente del campo URI de solicitud. Para el método POST, este URI especifica un recurso que gestionará la información contenida en el cuerpo de la solicitud como un apéndice. El recurso puede ser un proceso de procesamiento de datos, una puerta de enlace a algún otro protocolo o un recurso independiente que permita anotaciones. Por el contrario, el URI para una solicitud PUT identifica la información contenida en el Contenido de la Solicitud. El usuario de la solicitud PUT sabe exactamente qué URI pretende utilizar y el destinatario de la solicitud no debe intentar aplicar la solicitud a ningún otro recurso.

BORRAR

El método DELETE se utiliza para eliminar recursos identificados por un URI de solicitud. Los resultados de este método en el servidor se pueden cambiar mediante intervención humana (o algún otro medio). En principio, el cliente nunca puede estar seguro de que la operación de eliminación se completó, incluso si el código de estado enviado por el servidor indica que la acción fue exitosa. Sin embargo, el servidor no debería informar de éxito hasta que esté a punto de borrarse en el momento de la respuesta. este recurso o moverlo a algún área inalcanzable.

ENLACE

El método LINK establece relaciones entre el recurso existente especificado en el URI de solicitud y otros recursos existentes. La diferencia entre el método LINK y otros métodos que permiten establecer enlaces entre documentos es que el método LINK no permite pasar el Cuerpo de Solicitud en una solicitud, y que como resultado de este método no se crean nuevos recursos.

DESCONECTAR

El método UNLINK elimina una o más relaciones de vínculo para el recurso especificado en el URI de solicitud. Estas relaciones se pueden establecer utilizando el método LINK o algún otro método que admita el encabezado "Link". Eliminar un enlace a un recurso no significa que el recurso deje de existir o deje de estar disponible para referencias futuras.

Campos de encabezado de solicitud

Los campos de encabezado de solicitud permiten al cliente enviar al servidor información adicional sobre la solicitud y sobre el propio cliente.

Encabezado de solicitud = Aceptar | Aceptar juego de caracteres | Aceptar codificación |

Aceptar-Idioma | Autorización | Desde |

Si-Modificado-Desde |

Pragma | Referidor | Agente de usuario | encabezado de extensión

Además, se pueden definir encabezados adicionales a través del mecanismo de extensión; las aplicaciones que no los reconocen deben tratar estos encabezados como contenido de encabezado. Algunos de los campos del encabezado de la solicitud se analizarán a continuación. De Si el campo De está presente, debe contener correo electrónico completo

la dirección del usuario que controla el programa agente que realiza las solicitudes. Esta dirección debe especificarse en el formato definido en RFC 822. Formato de este campo

siguiente: From = "From" ":" especificación de dirección. Por ejemplo: De:[correo electrónico protegido] Este campo se puede utilizar para funciones de inicio de sesión, así como para identificar el origen de solicitudes incorrectas o no deseadas. No debe utilizarse como una forma no clasificada de control de acceso. La interpretación de este campo es que la solicitud que se procesa se realiza en nombre del usuario en cuestión, quien acepta la responsabilidad del método utilizado. En particular, los agentes del robot deben utilizar este encabezado para poder contactar con la persona responsable del robot si surgen problemas. La dirección de correo de Internet indicada en este campo no tiene por qué coincidir con la dirección del host desde el que se envió. esta solicitud . Si es posible, la dirección debe ser accesible. dirección de internet

independientemente de si en realidad es Internet

Si-modificado-desde

El campo de encabezado If-Modified-Since se utiliza con el método GET para hacerlo condicional: si el recurso solicitado no ha cambiado en el tiempo especificado en este campo, el servidor no devolverá una copia de ese recurso; en su lugar, se devolverá una respuesta "304 No modificado" sin cuerpo de respuesta.

If-Modified-Since = "If-Modified-Since" ":" Fecha HTTP

Ejemplo de uso de un encabezado:

El propósito de esta característica es permitir la actualización eficiente de la información de la caché local con un mínimo de información transmitida. El mismo resultado se puede lograr usando el método HEAD seguido de usando OBTENER si el servidor ha indicado que el contenido del documento ha cambiado.

Agente de usuario

El campo de encabezado User-Agent contiene información sobre el agente de usuario que envió la solicitud. Este campo se utiliza para estadísticas, seguimiento de errores de protocolo y reconocimiento automático agentes de usuario. Aunque no es obligatorio, los agentes de usuario siempre deben incluir este campo en sus solicitudes. El campo puede contener varias líneas que representan el nombre del producto de software, una barra diagonal opcional que indica la versión del producto y otros productos de software, que forman una parte importante del agente de usuario. Por convención, los productos se enumeran en orden descendente según su importancia para la identificación de la solicitud.

Agente-usuario = "Agente-usuario" ":" 1*(producto) producto = cadena ["/" versión-producto] versión-producto = cadena

Agente de usuario: CERN-LineMode/2.15 libwww/2.17b3

La línea que describe el nombre del producto debe ser breve y directa: no se permite utilizar este título para anunciar cualquier otra información irrelevante y se considerará incompatible con el protocolo. Aunque cualquier cadena puede estar presente en el campo de versión del producto, línea dada sólo debe utilizarse para indicar la versión del producto. El campo Usuario-Agente puede incluir información adicional en comentarios que no forman parte de su valor.

Estructura de respuesta

Después de recibir e interpretar la solicitud, el servidor envía una respuesta de acuerdo con el siguiente formulario:

Respuesta = Respuesta simple | Respuesta completa Respuesta simple = [Contenido de respuesta] Respuesta completa = Línea de estado *(Encabezado común | Encabezado de respuesta | Encabezado de contenido) CRLF [Contenido de respuesta]

Una respuesta simple solo debe enviarse en respuesta a una solicitud simple HTTP/0.9, o si el servidor solo admite el protocolo limitado HTTP/0.9. Si un cliente envía una solicitud completa HTTP/1.0 y recibe una respuesta que no comienza con una línea de estado, debe asumir que la respuesta del servidor es una respuesta simple y procesarla en consecuencia. Cabe señalar que la Respuesta Simple consta únicamente de la información solicitada (sin encabezados) y el flujo de datos se detiene en el momento en que el servidor cierra la sesión de comunicación.

Estado de la línea

La primera línea de la solicitud completa es una línea de estado que consta de la versión del protocolo seguida de código digital estado y la frase de texto asociada. Todos los elementos Line-Status están separados por espacios. No se permiten caracteres CR y LF, con la excepción de la secuencia CRLF final.

Estado-línea=Versión-HTTP Estado del SP-Código Frase del SP-Explicación.

Dado que la línea de estado siempre comienza con la versión del protocolo "HTTP/" 1*DIGIT "." 1*DÍGITO (por ejemplo, HTTP/1.0), la existencia de esta expresión se considera fundamental para determinar si la respuesta es una respuesta simple o una respuesta completa. Aunque el formato de respuesta simple no impide que aparezca dicha cadena (lo que llevaría a que el mensaje de respuesta se malinterprete como una respuesta completa), la probabilidad de que esto ocurra es cercana a cero.

Código de estado y explicación del mismo.

El elemento Código de estado es un código completo de 3 dígitos que identifica el resultado de un intento de interpretar y satisfacer la solicitud. La frase explicativa que sigue está destinada a una breve descripción textual del código de estado. El Código de Estado está destinado a ser utilizado por una máquina, mientras que la Frase Explicativa está destinada a una persona. El Cliente no está obligado a examinar y mostrar la Frase Explicativa.

El primer dígito del Código de Estado tiene como objetivo determinar la clase de la respuesta. Los dos últimos dígitos no desempeñan ningún papel categorizador. Hay 5 significados para el primer dígito:

1xx: Informativo: no utilizado, pero reservado para uso futuro
2xx: Éxito: la solicitud se recibió, entendió y aceptó en su totalidad para su procesamiento.
3xx: Redirección: el cliente debe tomar acciones adicionales para completar la solicitud con éxito. Necesario acción adicional A veces puede ser ejecutado por el cliente sin interacción del usuario, pero se recomienda encarecidamente que esto solo ocurra en los casos en que el método utilizado en la solicitud sea indiferente (GET o HEAD).
4xx: Error del cliente: una solicitud que contiene una sintaxis no válida no se puede completar correctamente. La clase 4xx está destinada a describir casos en los que se cometió un error por parte del cliente. Si el cliente aún no ha completado la solicitud cuando recibe una respuesta con el Código de estado - 4xx, debe dejar de transmitir datos al servidor inmediatamente. este tipo Los códigos de estado son aplicables a cualquier método utilizado en la solicitud.
5xx: Error del servidor: el servidor no pudo proporcionar una respuesta a una solicitud enviada correctamente. En estos casos
el servidor sabe que cometió un error o no puede procesar la solicitud. Con la excepción de las respuestas a solicitudes HEAD, el servidor envía una descripción de la situación del error y si la condición es temporal o permanente en el Contenido de respuesta. Este tipo de código de estado es aplicable a cualquier método utilizado en la solicitud.

Los significados individuales de los Códigos de Estado y las Frases Explicativas correspondientes se detallan a continuación. Estas Frases Explicativas sólo son recomendadas; pueden ser reemplazadas por cualquier otra frase que conserve su significado y esté permitida por el protocolo.

No es necesario que las aplicaciones HTTP comprendan todos los códigos de estado, aunque dicha comprensión es obviamente deseable. Sin embargo, se requiere que las aplicaciones puedan reconocer clases de códigos de estado (identificados por el primer dígito) y tratar todos los códigos de estado de respuesta como si fueran equivalentes al código de estado x00.

Campos de encabezado-respuesta

Los campos del encabezado de respuesta permiten al servidor pasar información adicional sobre la respuesta que no se puede incluir en la línea de estado. Estos campos de encabezado no pretenden transmitir información sobre el contenido de la respuesta enviada en respuesta a la solicitud, pero pueden contener información sobre el servidor en sí.

Encabezado de respuesta = Público | Reintentar después | Servidor | WWW-Autenticar | encabezado de extensión

A pesar de campos adicionales Los encabezados de respuesta se pueden implementar a través de un mecanismo de extensión; las aplicaciones que no reconocen estos campos deben tratarlos como campos de contenido de encabezado. Descripción completa Estos campos se pueden obtener de la especificación. protocolo HTTP en el CERN.

Conceptos generales

La solicitud completa y la respuesta completa se pueden utilizar para pasar cierta información a solicitudes individuales y respuestas. Esta información es el Contenido de la Solicitud o el Contenido de la Respuesta, respectivamente, y el Encabezado del Contenido.

Campos de título-contenido

Los campos Contenido del encabezado contienen metainformación opcional sobre el Contenido de la solicitud o el Contenido de la respuesta, respectivamente. Si el cuerpo del mensaje correspondiente (solicitud o respuesta) no está presente, entonces el encabezado de contenido contiene información sobre el recurso solicitado.

Algunos de los campos del encabezado de contenido se describen a continuación.

Permitir

El campo de encabezado Permitir es una lista de métodos que admite el recurso identificado por el URI de solicitud. El propósito de este campo es informar con precisión al destinatario de los métodos válidos asociados con el recurso; este campo debe estar presente en la respuesta con el código de estado "Método 405 no permitido".

Permitir = "Permitir" ":" 1#método

Ejemplo de uso:

Permitir: OBTENER, CABEZA, PONER

Por supuesto, el cliente puede probar otros métodos. Sin embargo, se recomienda seguir los métodos indicados en este campo. Este campo no tiene valor predeterminado; Si no se define, el conjunto de métodos permitidos lo determina el servidor en el momento de cada solicitud.

Longitud del contenido

El campo Content-Length especifica el tamaño del cuerpo del mensaje enviado por el servidor en respuesta a la solicitud o, en el caso de una solicitud HEAD, el tamaño del cuerpo del mensaje que se enviaría en respuesta a la solicitud GET.

Longitud del contenido = "Longitud del contenido" ":" 1*DÍGITO

Por ejemplo:

Longitud del contenido: 3495

Aunque no es obligatorio, se recomienda encarecidamente que las aplicaciones utilicen este campo para analizar el tamaño del mensaje que se transmite, independientemente del tipo de información que contenga. Para el campo Longitud del contenido, cualquier valor entero mayor que cero es válido.

Tipo de contenido

El campo de encabezado Content-Type identifica el tipo de información en el cuerpo del mensaje que se envía a la parte receptora o, en el caso del método HEAD, el tipo de información (medios) que se enviaría si se utilizara el método GET.

Tipo de contenido = "Tipo de contenido" ":" tipo de entorno

Los tipos de medios se definen por separado.
Ejemplo:

Tipo de contenido: texto/html; juego de caracteres=ISO-8859-4

El campo Tipo de contenido no tiene valor predeterminado.

Última modificación

El campo de encabezado contiene la fecha y hora en la que la parte remitente cree que el recurso se modificó por última vez. La semántica de este campo se define en términos que describen cómo el destinatario debe interpretarlo: si el destinatario tiene una copia del recurso que es anterior a la fecha ingresada en el campo Última modificación, entonces la copia debe considerarse obsoleta. .

Última modificación = "Última modificación" ":" Fecha HTTP

Ejemplo de uso:

El significado exacto de este campo de encabezado depende de la implementación del remitente y de la naturaleza del recurso en sí. Para los archivos, esta podría ser simplemente la hora de su última modificación. Para las puertas de enlace de bases de datos, esta puede ser la hora en que se actualizaron por última vez los datos de la base de datos. En cualquier caso, el destinatario sólo tiene que preocuparse por el resultado (lo que hay en el campo dado) y no preocuparse por cómo se obtuvo el resultado.

Cuerpo del mensaje

El cuerpo del mensaje se refiere al contenido de la solicitud o al contenido de la respuesta, respectivamente. El cuerpo del mensaje, si está presente, se envía en la solicitud o respuesta HTTP/1.0 en el formato y codificación especificados en los campos Contenido del encabezado.

Cuerpo del mensaje = *OCTETO (donde OCTET es cualquier carácter de 8 bits)

El cuerpo del mensaje se incluye en la solicitud sólo si el método de solicitud implica su presencia. Para la especificación HTTP/1.0, estos métodos son POST y PUT. En general, la presencia de un cuerpo de mensaje se indica mediante la presencia de campos de encabezado de contenido como Content-Length y/o Content-Transfer-Encoding en la solicitud transmitida.

Después de leer este artículo, aprenderá por qué es tan importante utilizar la compresión y qué impacto puede tener en su sitio web. Este artículo se basa en dos claves...

HTTP. Se basa en la interacción" cliente-servidor", es decir, se supone que:

Consumidor- cliente habiendo iniciado una conexión con el servidor-proveedor, le envía una solicitud;
Proveedor- servidor, habiendo recibido la solicitud, realiza las acciones necesarias y devuelve una respuesta con el resultado al cliente.
En este caso, hay dos formas posibles de organizar el trabajo de la computadora cliente:
- Cliente ligero Es una computadora cliente que transfiere todas las tareas de procesamiento de información al servidor. Un ejemplo de cliente ligero es una computadora con un navegador que se utiliza para trabajar con aplicaciones web.
- cliente gordo, por el contrario, procesa la información independientemente del servidor, utilizando este último principalmente únicamente para el almacenamiento de datos.

Antes de pasar a tecnologías web cliente-servidor específicas, consideremos los principios y la estructura básicos. protocolo básico HTTP.

protocolo HTTP

HTTP (Protocolo de transferencia de hipertexto - RFC 1945, RFC 2616) - protocolo nivel de aplicación para la transmisión de hipertexto.

La entidad central en HTTP es recurso La URL señalada en la solicitud del cliente. Normalmente, estos recursos son archivos almacenados en el servidor. Una característica del protocolo HTTP es la capacidad de especificar en la solicitud y respuesta el método de representación del mismo recurso según varios parámetros: formato, codificación, idioma, etc. Es gracias a la capacidad de especificar el método de codificación de un mensaje. que el cliente y el servidor pueden intercambiar datos binarios, aunque inicialmente este protocolo diseñado para transmitir información simbólica. A primera vista, esto puede parecer un desperdicio de recursos. De hecho, los datos en forma simbólica ocupan más memoria, los mensajes crean una carga adicional en los canales de comunicación, pero este formato tiene muchas ventajas. Los mensajes transmitidos a través de la red son legibles y, después de analizar los datos recibidos, administrador del sistema Puede encontrar fácilmente el error y solucionarlo. Si es necesario, una persona puede desempeñar el papel de una de las aplicaciones interactivas ingresando mensajes manualmente en el formato requerido.

A diferencia de muchos otros protocolos, HTTP es un protocolo sin memoria. Esto significa que el protocolo no almacena información sobre solicitudes anteriores de clientes y respuestas del servidor. Los componentes que utilizan HTTP pueden mantener de forma independiente la información de estado asociada con solicitudes y respuestas recientes. Por ejemplo, cliente aplicación web, enviar solicitudes, puede monitorear los retrasos en las respuestas y servidor web Puede almacenar direcciones IP y solicitar encabezados de clientes recientes.

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

Servidores- proveedores de servicios de almacenamiento y procesamiento de información (procesamiento de solicitudes).
Clientela- consumidores finales de servicios de servidor (envío de solicitudes).
Servidores proxy para apoyar el trabajo de los servicios de transporte.

Los principales clientes son navegadores por ejemplo: internet Explorador, Opera, Mozilla Firefox, Netscape Navegante y otros. Las implementaciones de servidores web más populares son: Internet Información Servicios (IIS), Apache, lighttpd, nginx. Las implementaciones de servidores proxy más conocidas: Squid, UserGate, Multiproxy, Naviscope.

El esquema de sesión HTTP "clásico" se ve así.

Estableciendo una conexión TCP.
Solicitud del cliente.
Respuesta del servidor.
Terminando la conexión TCP.

Por lo tanto, el cliente envía una solicitud al servidor, recibe una respuesta del mismo y luego se detiene la interacción. Normalmente, la solicitud del cliente es una solicitud para transferir un documento HTML o algún otro recurso, y la respuesta del servidor contiene el código para este recurso.

La solicitud HTTP enviada por el cliente al servidor incluye los siguientes componentes.

Línea de estado (a veces también se utilizan los términos línea de estado o línea de consulta para referirse a ella).
Campos de encabezado.
Cadena vacía.
Cuerpo de solicitud.

barra de estado junto con campos de encabezado a veces también llamado encabezado de solicitud.

Arroz. 2.1.

barra de estado tiene el siguiente formato:

método_solicitud URL_pecypca versión_protocolo HTTP

Veamos los componentes de la barra de estado, con atención especial Centrémonos en los métodos de consulta.

Método especificado en la línea de estado determina cómo se ve afectado el recurso cuya URL se especifica en la misma línea. El método puede tomar los valores GET, POST, HEAD, PUT, DELETE, etc. A pesar de la abundancia de métodos, sólo dos de ellos son realmente importantes para un programador web: GET y POST.

CONSEGUIR. Según la definición formal, el método GET tiene como objetivo obtener un recurso con URL especificada. Al recibir una solicitud GET, el servidor debe leer el recurso especificado e incluir el código del recurso como parte de la respuesta al cliente. El recurso cuya URL se pasa como parte de la solicitud no tiene que ser una página HTML, un archivo de imagen u otros datos. La URL del recurso puede apuntar a código ejecutable programa que, sujeto a ciertas condiciones, debe iniciarse en el servidor. En este caso, al cliente no se le devuelve el código del programa, sino los datos generados durante su ejecución. Aunque, por definición, el método GET está destinado a recuperar información, puede utilizarse para otros fines. El método GET es muy adecuado para transferir pequeños datos al servidor.
CORREO. Según la misma definición formal, el objetivo principal del método POST es transferir datos al servidor. Sin embargo, al igual que el método GET, el método POST se puede utilizar de muchas maneras diferentes y, a menudo, se utiliza para recuperar información de un servidor. Al igual que con el método GET, la URL especificada en la barra de estado apunta a un recurso específico. El método POST también se puede utilizar para iniciar un proceso.
Los métodos HEAD y PUT son modificaciones de los métodos GET y POST.

Versión del protocolo HTTP normalmente se especifica en el siguiente formato:

HTTP/versión.modificación

Campos de encabezado, siguiendo la línea de estado, le permite refinar la solicitud, es decir. transmitir información adicional al servidor. El campo de encabezado tiene el siguiente formato:

Nombre de campo: Valor

El propósito de un campo está determinado por su nombre, que está separado del valor por dos puntos.

Los nombres de algunos de los campos de encabezado más comunes en una solicitud de cliente y su propósito se muestran en la Tabla 2.1.

Tabla 2.1.

Campos de encabezado Campos de encabezado de solicitud HTTP. HTTP	-pedido
Significado	Anfitrión
Nombre de dominio o dirección IP del host al que accede el cliente	referente
URL del documento que hace referencia al recurso que aparece en la barra de estado	De DIRECCIÓN correo electrónico
usuario trabajando con un cliente	Aceptar Tipos MIME de datos procesados por el cliente. Este campo puede tener varios valores, separados por comas. A menudo, el campo de encabezado Aceptar se utiliza para indicarle al servidor qué tipos archivos gráficos
soporte al cliente	Aceptar-Idioma
Un conjunto de identificadores de dos caracteres, separados por comas, que indican los idiomas admitidos por el cliente.	Aceptar juego de caracteres
Lista de juegos de caracteres admitidos	Tipo de contenido
Tipo MIME de datos contenidos en el cuerpo de la solicitud (si la solicitud no consta de un único encabezado)	Longitud del contenido
Número de caracteres contenidos en el cuerpo de la solicitud (si la solicitud no consta de un solo encabezado)	Rango
Presente si el cliente no solicita el documento completo, sino solo una parte	Conexión
Se utiliza para gestionar la conexión TCP. Si el campo contiene Cerrar, esto significa que el servidor debe cerrar la conexión después de procesar la solicitud. El valor Keep-Alive sugiere mantener abierta la conexión TCP para que pueda usarse para solicitudes posteriores.	Agente de usuario

Información del cliente

En muchos casos, cuando se trabaja en la Web, no existe un cuerpo de solicitud. Cuando se ejecutan scripts CGI, los datos que se les pasan en la solicitud se pueden colocar en el cuerpo de la solicitud. HTTP (Protocolo de transferencia de hipertexto - "protocolo de transferencia de hipertexto") - un protocolo de capa de aplicación para la transferencia de datos (inicialmente, en el formulario documentos de hipertexto ). La base de HTTP es la tecnología cliente-servidor, es decir, asume la existencia de consumidores (clientes) que inician la conexión y envían una solicitud, y proveedores (servidores) que esperan la conexión para recibir la solicitud y realizar acciones necesarias

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 el URI (Identificador uniforme de recursos) en la solicitud del 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 respuesta el método de representación del mismo recurso según varios parámetros: formato, codificación, idioma, etc. Es gracias a la capacidad de especificar el método de codificación de un 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, similar a FTP y SMTP (Protocolo simple de transferencia de correo). 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 hay persistencia del estado intermedio entre los pares solicitud-respuesta. Los componentes que utilizan HTTP pueden mantener de forma independiente información de estado asociada con solicitudes y respuestas recientes. El navegador que envía las solicitudes puede realizar un seguimiento de los retrasos en las respuestas. El servidor puede almacenar las direcciones IP y solicitar encabezados de los clientes más recientes. Sin embargo, el protocolo en sí no tiene conocimiento de solicitudes y respuestas anteriores, no proporciona apoyo estatal interno y no se le imponen tales requisitos.

Extensibilidad

Las capacidades del protocolo se pueden ampliar fácilmente introduciendo el suyo propio. títulos propios, manteniendo la compatibilidad con otros clientes y servidores. Ignorarán los encabezados desconocidos para ellos, pero al mismo tiempo pueden obtener la funcionalidad necesaria para resolver problemas específicos.

HTTP/1.1 - versión actual protocolo. Una novedad en esta versión fue el 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 una sola conexión. Ahora se requiere que el cliente envíe información sobre el nombre del host al que accede, lo que permitió organizar el hosting virtual más fácilmente.

HTTP no almacena información sobre transacciones, por lo que debe comenzar de nuevo en la siguiente transacción. La ventaja es que servidor HTTP pueden atender a muchos más clientes en un período de tiempo determinado, porque eliminan costos adicionales para realizar un seguimiento de las sesiones de una conexión a otra. También hay un inconveniente: para guardar la información de las transacciones, se deben utilizar programas CGI más complejos. campos ocultos entrada o por medios externos, por ejemplo galleta.

Métodos de solicitud HTTP

método HTTP- una secuencia de cualquier carácter, excepto controles y separadores, que indique la operación principal en el recurso. Normalmente el método es corto palabra inglesa, grabado en mayúsculas. Tenga en cuenta que el nombre del método distingue entre mayúsculas y minúsculas.

Cada servidor debe soportar al menos los métodos GET y HEAD. Si el servidor no reconoce el método especificado por el cliente, entonces debería devolver el estado 501 (No implementado). Si el servidor conoce el método, pero no es aplicable a recurso específico, luego se devuelve un mensaje con el código 405 (Método no permitido). En ambos casos, el servidor DEBE incluir un encabezado Permitir en el mensaje de respuesta con una lista de métodos admitidos.

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

Solicitud HTTP, respuesta, encabezados de entidad (parámetros)

Todos los encabezados del protocolo HTTP se dividen en cuatro grupos principales (se recomienda enviar los encabezados al destinatario en el siguiente orden):
Todos los encabezados necesarios para que HTTP funcione se describen en los RFC principales. Si es necesario, puedes crear tus propios títulos. Tradicionalmente, los nombres de dichos encabezados adicionales tienen el prefijo "X-" para evitar conflictos de nombres con los que posiblemente existan.

Las líneas después de la línea de solicitud principal (GET /index.html HTTP/1.1) tienen el siguiente formato: Parámetro: valor. Así es como se configuran los parámetros de la solicitud. Esto es opcional; es posible que falten todas las líneas después de la línea de consulta principal; en este caso, el servidor acepta su valor por defecto o en función de los resultados de la solicitud anterior (cuando se trabaja en Conexión: modo Keep-Alive).
Para documentos SSI, Apache emitirá "Última modificación" si se especifica la directiva "XBitHack full" (por ejemplo, en el archivo .htaccess)
Otros encabezados HTTP:
- HTTP_X_COMING_FROM
  
  HTTP_COMING_FROM
- HTTP_X_CLUSTER_CLIENT_IP
- HTTP_XROXY_CONNECTION
  
  HTTP_PROXY_CONNECTION
  
  HTTP_USERAGENT_VIA - proxy
Ejemplo de análisis de solicitudes HTTP

Una solicitud HTTP consta de tres partes: una línea de solicitud (respuesta), una sección de encabezado y un cuerpo opcional. Los encabezados son texto sin formato, con cada encabezado separado del siguiente por un carácter de nueva línea (\r\n), mientras que el cuerpo puede ser texto o datos binarios. El cuerpo está separado de los encabezados por dos nuevas líneas.

El encabezado de la solicitud consta de la línea principal (primera) de la solicitud y líneas posteriores que aclaran la solicitud en la línea principal. Es posible que también falten líneas posteriores.

El cliente inicia una transacción de la siguiente manera:
El servidor responde a la solicitud del cliente de la siguiente manera:
código de estado HTTP

código de estado HTTP es parte de la primera línea de la respuesta del servidor. Es un número entero de tres dígitos. El primer dígito indica la clase de la condición. El código de respuesta suele ir seguido de una frase explicativa separada por un espacio. Inglés, que explica a la persona el motivo de esta respuesta en particular.

Es posible que el cliente no conozca todos los códigos de estado, pero debe responder de acuerdo con la clase del código. Actualmente existen cinco clases de códigos de estado:
Enlaces relacionados con HTTP 1.1

HTTP/2

HTTP/2 (originalmente HTTP/2.0) - segunda versión principal protocolo de red HTTP. El protocolo se basa en SPDY (protocolo compatible con HTTP desarrollado por Google).

El protocolo HTTP/2 es binario. En comparación con el estándar anterior, se han cambiado los métodos para dividir los datos en fragmentos y transportarlos entre el servidor y el cliente.

En HTTP/2, el servidor tiene derecho a enviar contenido que aún no ha sido solicitado por el cliente. Esto permitirá que el servidor envíe inmediatamente archivos adicionales, que el navegador necesitará para mostrar las páginas, sin que el navegador tenga que analizar la página principal y solicitar las adiciones necesarias.

HTTP (Protocolo de transferencia de hipertexto) se desarrolló como base de la World Wide Web.

El protocolo HTTP funciona de la siguiente manera: el programa cliente establece una conexión TCP con el servidor (número de puerto estándar 80) y le envía una solicitud HTTP. El servidor procesa esta solicitud y emite una respuesta HTTP al cliente.

Estructura de solicitud HTTP

Una solicitud HTTP consta de un encabezado de solicitud y un cuerpo de solicitud, separados por una línea vacía. Es posible que falte el cuerpo de la solicitud.

El encabezado de la solicitud consta de la línea principal (primera) de la solicitud y líneas posteriores que aclaran la solicitud en la línea principal. Es posible que también falten líneas posteriores.

La consulta de la línea principal consta de tres partes, separadas por espacios:

Método(en otras palabras, el comando HTTP):

CONSEGUIR- solicitud de documentos. El método más utilizado; en HTTP/0.9, dicen, él era el único.

CABEZA- solicitud de título del documento. Se diferencia de GET en que sólo se devuelve el encabezado de la solicitud con información sobre el documento. El documento en sí no se emite.

CORREO- este método se utiliza para transferir datos a scripts CGI. Los datos en sí aparecen en las líneas siguientes de la solicitud en forma de parámetros.

PONER- colocar el documento en el servidor. Hasta donde yo sé, rara vez se usa. Una solicitud con este método tiene un cuerpo en el que se transmite el documento en sí.

Recurso- esta es la manera de archivo específico en el servidor que el cliente desea recibir (o colocar, para el método PUT). Si el recurso es simplemente un archivo para leer, el servidor debe devolverlo en el cuerpo de respuesta de esta solicitud. Si esta es la ruta a un script CGI, entonces el servidor ejecuta el script y devuelve el resultado de su ejecución. Por cierto, gracias a esta unificación de recursos, el cliente es prácticamente indiferente a lo que representa en el servidor.

Versión del protocolo-versión del protocolo HTTP con el que trabaja el programa cliente.

Entonces, una solicitud HTTP simple podría verse así:

Esto solicita el archivo raíz del directorio raíz del servidor web.

Las líneas después de la línea de consulta principal tienen el siguiente formato:

Parámetro: valor.

Así es como se configuran los parámetros de la solicitud. Esto es opcional; es posible que falten todas las líneas después de la línea de consulta principal; en este caso, el servidor acepta su valor por defecto o en función de los resultados de la solicitud anterior (cuando se trabaja en modo Keep-Alive).

Enumeraré algunos de los parámetros de solicitud HTTP más utilizados:

Presente si el cliente no solicita el documento completo, sino solo una parte(conexión): puede tomar los valores Keep-Alive y cerrar. Keep-Alive significa que después de emitir este documento, la conexión con el servidor no se interrumpe y se pueden emitir más solicitudes. La mayoría de los navegadores funcionan en modo Keep-Alive, ya que le permite "descargar" una página html e imágenes en una sola conexión al servidor. Una vez configurado, el modo Keep-Alive se mantiene hasta el primer error o hasta que se especifique explícitamente la siguiente conexión: cerrar solicitud.
cerrar ("cerrar"): la conexión se cierra después de responder a esta solicitud.

Se utiliza para gestionar la conexión TCP. Si el campo contiene Cerrar, esto significa que el servidor debe cerrar la conexión después de procesar la solicitud. El valor Keep-Alive sugiere mantener abierta la conexión TCP para que pueda usarse para solicitudes posteriores.- el valor es el "código" del navegador, por ejemplo:

Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt)

usuario trabajando con un cliente- una lista de tipos de contenido admitidos por el navegador en orden de preferencia para un navegador determinado, por ejemplo para mi IE5:

Aceptar: imagen/gif, imagen/x-xbitmap, imagen/jpeg, imagen/pjpeg, aplicación/vnd.ms-excel, aplicación/msword, aplicación/vnd.ms-powerpoint, */*

Obviamente, esto es necesario en el caso en que el servidor pueda generar el mismo documento en diferentes formatos.

El valor de este parámetro lo utilizan principalmente los scripts CGI para generar una respuesta adaptada a un navegador determinado.

Nombre de dominio o dirección IP del host al que accede el cliente- URL desde la que llegó a este recurso.

Significado- el nombre del host desde el que se solicita el recurso. Útil si el servidor tiene varios servidores virtuales bajo la misma dirección IP. En este caso el nombre servidor virtual determinado por este campo.

soporte al cliente- idioma soportado. Importante para un servidor que puede entregar el mismo documento en versiones de diferentes idiomas.

formato de respuesta HTTP

El formato de respuesta es muy similar al formato de solicitud: también tiene un encabezado y un cuerpo separados por una línea vacía.

El encabezado también consta de una línea principal y líneas de parámetros, pero el formato de la línea principal es diferente al del encabezado de la solicitud.

La cadena de consulta principal consta de 3 campos separados por espacios:

Versión del protocolo- similar al parámetro de solicitud correspondiente.

código de error- designación del código del “éxito” de la solicitud. El código 200 significa "todo está bien" (OK).

Descripción verbal del error.- “descifrar” el código anterior. Por ejemplo, para 200 está bien, para 500 es un error interno del servidor.

Los parámetros de respuesta http más comunes:

Presente si el cliente no solicita el documento completo, sino solo una parte- similar al parámetro de solicitud correspondiente.
Si el servidor no admite Keep-Alive (hay algunos), entonces el valor de Conexión en la respuesta siempre está cerca.

Por tanto, en mi opinión, la táctica correcta del navegador es la siguiente:
1. emitir Conexión: Keep-Alive en la solicitud;
2. El estado de la conexión se puede juzgar por el campo Conexión en la respuesta.

Lista de juegos de caracteres admitidos(“tipo de contenido”): contiene una designación del tipo de contenido de la respuesta.

Dependiendo del valor del tipo de contenido, el navegador interpreta la respuesta como una página HTML, imagen gif o jpeg, como un archivo para guardar en el disco, o lo que sea, y toma las medidas adecuadas. El valor de tipo de contenido para el navegador es el mismo que el valor de extensión de archivo para Windows.

Algunos tipos de contenido:

text/html - texto en formato HTML (página web);
texto/plain - texto plano (similar al Bloc de notas);
image/jpeg - imagen en formato JPEG;
imagen/gif - lo mismo, en formato GIF;
application/octet-stream: un flujo de "octetos" (es decir, solo bytes) para escribir en el disco.

En realidad, existen muchos más tipos de contenido.

Tipo MIME de datos contenidos en el cuerpo de la solicitud (si la solicitud no consta de un único encabezado)("longitud del contenido"): la longitud del contenido de la respuesta en bytes.

Última modificación(“Última modificación”): la fecha en que se modificó por última vez el documento.

Popular en la categoría: