Hogar › Tarifas › El protocolo http es para transmisión. Protocolo de transferencia de hipertexto. Herramientas para detectar tráfico HTTP

El protocolo http es para transmisión. Protocolo de transferencia de hipertexto. Herramientas para detectar tráfico HTTP

Idioma, etc. Debido a la capacidad de especificar cómo se codifica un mensaje, el cliente y el servidor pueden intercambiar datos binarios, aunque este protocolo es texto.

Ventajas

Sencillez

El protocolo es tan sencillo de implementar que facilita la creación de aplicaciones cliente.

Extensibilidad

Puede ampliar fácilmente las capacidades del protocolo introduciendo el suyo propio. títulos propios, manteniendo la compatibilidad con otros clientes y servidores. Ignorarán los encabezados que no conocen, pero al mismo tiempo usted puede obtener la funcionalidad que necesita para resolver un problema específico.

Predominio

Al elegir el protocolo HTTP para resolver problemas específicos, un factor importante es su prevalencia. Como resultado, se trata de una gran cantidad de documentación diversa sobre el protocolo en muchos idiomas del mundo, la inclusión de herramientas de desarrollo fáciles de usar en IDE populares, soporte para el protocolo como cliente en muchos programas. y una amplia elección entre empresas de hosting con servidores HTTP.

Desventajas y problemas

Tamaño de mensaje grande

El uso de un formato de texto en el protocolo genera una desventaja correspondiente: el gran tamaño de los mensajes en comparación con la transferencia de datos binarios. Debido a esto, aumenta la carga sobre el equipo al generar, procesar y transmitir mensajes. Para resolver este problema, el protocolo incluye medios integrados para el almacenamiento en caché en el lado del cliente, así como medios para comprimir el contenido transmitido. Los documentos reglamentarios del protocolo prevén la presencia de servidores proxy, que permiten al cliente recibir un documento del servidor más cercano a él. Además, se introdujo la codificación delta en el protocolo para que no se transmitiera al cliente todo el documento, sino solo la parte modificada.

Falta de "navegación"

Aunque el protocolo fue desarrollado como un medio para trabajar con recursos del servidor, carece explícitamente medios de navegación entre estos recursos. Por ejemplo, el cliente no puede solicitar explícitamente una lista de archivos disponibles, como en . Se supuso que el usuario final ya conocía los hipervínculos. Esto es bastante normal y conveniente para los humanos, pero resulta difícil cuando la tarea es procesar y analizar automáticamente todos los recursos del servidor sin intervención humana. La solución a este problema recae enteramente en los desarrolladores de aplicaciones que utilizan este protocolo.

Sin soporte de distribución

El protocolo HTTP fue desarrollado para resolver problemas cotidianos típicos, donde el tiempo de procesamiento de solicitudes en sí debería tomar poco tiempo o no tomarse en cuenta en absoluto. pero en uso industrial usando computación distribuida cargas altas El protocolo HTTP resulta indefenso en el servidor. En 1998, el W3C propuso un protocolo alternativo HTTP-NG(Inglés) HTTP de próxima generación) Para reemplazo completo obsoleto con un enfoque en esta área. La idea de su necesidad fue apoyada por grandes especialistas en informática distribuida, pero este protocolo aún se encuentra en etapa de desarrollo.

Software

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

Servidores como principales proveedores de servicios de almacenamiento y procesamiento de información (procesamiento de solicitudes).
Clientela- consumidores finales de servicios de servidor (envío de una solicitud).
Apoderado para realizar servicios de transporte.

Para distinguir los servidores finales de los proxies, la documentación oficial utiliza el término servidor de origen(Inglés) Servidor de origen). Por supuesto, un mismo producto de software puede realizar simultáneamente las funciones de cliente, servidor o intermediario, dependiendo de las tareas asignadas. Las especificaciones del protocolo HTTP detallan el comportamiento de cada uno de estos roles.

Clientela

El protocolo HTTP se desarrolló originalmente para acceder a documentos de hipertexto en la World Wide Web. Por lo tanto, las principales implementaciones de clientes son navegadores(agentes de usuario). Navegadores populares (en orden alfabético): Chrome, Internet Explorer, Mozilla Firefox, Safari.

Ver también: Lista de navegadores y Comparación de navegadores

Para ver el contenido guardado de los sitios en una computadora sin conexión a Internet, se inventaron navegadores sin conexión. Entre los famosos. Te permiten descargar en cualquier momento. archivos especificados después de perder la conexión con el servidor web. Los programas populares en el sistema operativo Windows son Download Master, Free Administrador de descargas, ReObtener. En KGet y d4x (Descargador para X). Muchos usuarios de Linux prefieren utilizar NASA World Wind, que también utiliza HTTP.

Los programas suelen utilizar el protocolo HTTP para descargar actualizaciones.

En los motores de búsqueda de Internet se utiliza una amplia gama de programas robóticos. entre ellos arañas web(rastreadores) que siguen hipervínculos, compilan una base de datos de recursos del servidor y guardan su contenido para su posterior análisis.

Ver también: Lista de motores de búsqueda, Internet Archive

Servidores de origen

Principales implementaciones: Internet Information Services (IIS), nginx.

Ver también: Lista de servidores web

Servidores proxy

Principales implementaciones: UserGate, Multiproxy, Naviscope, Lista de servidores web

Historia del desarrollo

HTTP/0.9

HTTP/1.0

HTTP/1.1

La versión actual del protocolo fue adoptada en junio. Lo nuevo en esta versión fue el modo de “conexión permanente”: Línea de salida) - determina el tipo de mensaje;

Encabezamientos Encabezados) - caracterizar el cuerpo del mensaje, los parámetros de transmisión y otra información;

Cuerpo del mensaje Cuerpo del mensaje) - datos del mensaje en sí. Debe estar separado de los encabezados por una línea en blanco.

Es posible que falten encabezados y cuerpo del mensaje, pero la línea de inicio es un elemento obligatorio ya que indica el tipo de solicitud/respuesta. Una excepción es la versión 0.9 del protocolo, en la que el mensaje de solicitud contiene solo la línea de inicio y el mensaje de respuesta contiene solo el cuerpo del mensaje.

Línea de salida

Las líneas de partida son diferentes para la solicitud y la respuesta. La cadena de consulta se ve así:

CONSEGUIR URI- para la versión de protocolo 0.9. Método URI HTTP/ Versión- para otras versiones.

Para solicitar una página para un artículo determinado, el cliente debe pasar la cadena:

OBTENER /wiki/Http HTTP/1.0

La línea inicial de la respuesta del servidor tiene el siguiente formato:

HTTP/ Versión Código de estado Explicación

Versión- un par de números arábigos separados por un punto, como en la solicitud.
Código de estado(Inglés) Código de estado) - tres números arábigos. El código de estado determina el contenido adicional del mensaje y el comportamiento del cliente.
Explicación(Inglés) Frase de razón): una breve explicación textual del código de respuesta para el usuario. No afecta el mensaje de ninguna manera y es opcional.

Por ejemplo, el servidor respondió a nuestra solicitud anterior del cliente para esta página con la línea:

HTTP/1.0 200 Aceptar

Métodos

OPCIONES

Se utiliza para definir las capacidades del servidor web o los parámetros de conexión para recurso específico. El servidor DEBE incluir un encabezado Permitir en su respuesta con una lista de métodos admitidos. Los encabezados de respuesta también pueden incluir información sobre las extensiones admitidas.

Se espera que la solicitud del cliente pueda contener un cuerpo de mensaje para indicar la información que le interesa. Formato del cuerpo y procedimiento para trabajar con él. momento presente no definido. 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. OPCIONES * Las solicitudes HTTP/1.1 también se pueden utilizar para verificar el estado del servidor (similar al ping) y para probar si el servidor admite la versión HTTP 1.1.

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

CONSEGUIR

Se utiliza para consultar el contenido de un recurso específico. También puede iniciar un proceso utilizando el método GET. En este caso, se debe incluir información sobre el progreso del proceso en el cuerpo del mensaje de respuesta.

El cliente puede pasar parámetros de ejecución de solicitud en el URI del recurso de destino después de "? ":
OBTENER /ruta/recurso?param1=valor1¶m2=valor2 HTTP/1.1

Según el estándar HTTP, las solicitudes escriba OBTENER se consideran idempotentes: repetir la misma solicitud GET varias veces debería producir los mismos resultados (siempre que el recurso en sí no haya cambiado en el tiempo entre solicitudes). Esto permite almacenar en caché las respuestas a las solicitudes GET.

Excepto método convencional GET, también hay una distinción entre . Las solicitudes GET condicionales contienen encabezados If-Modified-Since, If-Match, If-Range y similares. Los GET parciales contienen Rango en la solicitud. El procedimiento para ejecutar dichas solicitudes está definido por separado en las normas.

CABEZA

Similar al método GET, excepto que no hay ningún cuerpo en la respuesta del servidor. La solicitud HEAD se utiliza normalmente para recuperar metadatos, comprobar la existencia de un recurso (validación de URL) y ver si ha cambiado desde la última vez que se accedió a él.

Los encabezados de respuesta pueden almacenarse en caché. Si los metadatos de un recurso no coinciden con la información correspondiente en el caché, la copia del recurso se marca como desactualizada.

CORREO

Se utiliza para transferir datos del usuario a un recurso específico. Por ejemplo, en los blogs, los visitantes normalmente pueden ingresar sus comentarios sobre las publicaciones en un formulario HTML, después de lo cual se PUBLICAN en el servidor y se colocan en la página. En este caso, los datos transmitidos (en el ejemplo de blogs, el texto del comentario) se incluyen en el cuerpo de la solicitud. De manera similar, los archivos generalmente se cargan mediante el método POST.

A diferencia del método GET, el método POST no se considera idempotente, lo que significa que repetir las mismas solicitudes POST varias veces puede generar resultados diferentes (por ejemplo, después de enviar cada comentario, aparecerá una copia de ese comentario).

Si los resultados de la ejecución son 200 (OK) y 204 (Sin contenido), se debe incluir un mensaje sobre el resultado de la solicitud en el cuerpo de la respuesta. Si se ha creado un recurso, el servidor DEBE devolver una respuesta 201 (Creado) con el URI del nuevo recurso en el encabezado Ubicación.

El mensaje de respuesta del servidor al método POST no se almacena en caché.

PONER

Se utiliza para cargar el contenido de la solicitud en el URI especificado en la solicitud. Si un recurso no existe en el URI dado, el servidor lo crea y devuelve el estado 201 (Creado). Si se ha cambiado el recurso, el servidor devuelve 200 (Aceptar) o 204 (Sin contenido). El servidor NO DEBE ignorar los encabezados Content-* no válidos 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 debe devolver un código de error 501 (No implementado).

La diferencia fundamental entre los métodos POST y PUT está en comprender los propósitos URI de recursos. El método POST supone que el URI especificado se utilizará para procesar el contenido enviado por el cliente. Al utilizar PUT, el cliente asume que el contenido que se descarga coincide con el recurso ubicado en el URI determinado.

Los mensajes de respuesta del servidor al método PUT no se almacenan en caché.

PARCHE

Similar a PUT, pero se aplica sólo a una parte del recurso.

BORRAR

Elimina el recurso especificado.

RASTRO

Devuelve la solicitud recibida para que el cliente pueda ver qué servidores intermedios están agregando o cambiando a la solicitud.

CONECTAR

Para usar con servidores proxy que pueden cambiar dinámicamente al modo túnel

ENLACE

Establece una conexión entre el recurso especificado y otros.

DESCONECTAR

Elimina la conexión del recurso especificado con otros.

Códigos de estado

El código de estado es parte de la primera línea de la respuesta del servidor. Representa un número entero de 3 números arábigos. El primer dígito indica clase de condición. El código de respuesta suele ir seguido de una frase explicativa separada por un espacio. Inglés, que indica el motivo de esta respuesta en particular.

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 todos se describen en los documentos pertinentes del IETF. 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.

1xx informativo (ruso) Informativo) Esta clase contiene códigos que informan 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 mensajes como una respuesta normal, pero no necesita enviar nada al servidor. Los propios mensajes del servidor contienen sólo la línea de inicio de la respuesta y, si es necesario, algunos campos de encabezado específicos de la respuesta. Servidores proxy mensajes similares debe enviarse más desde el servidor al cliente. 2xx Éxito (ruso) Exitosamente ) Los mensajes de esta clase informan sobre casos de aceptación y procesamiento exitosos de una solicitud de cliente. Dependiendo del estado, el servidor también puede transmitir los encabezados y el cuerpo del mensaje. Redirección 3xx (ruso) Redirección) Los códigos de estado de clase 3xx le indican al cliente que la siguiente solicitud debe realizarse a un URI diferente para que la operación se realice correctamente. En la mayoría de los casos, la nueva dirección se indica en el campo Ubicación del encabezado. En este caso, el cliente deberá, por regla general, hacer transición automática(jerga. redirigir). Tenga en cuenta que cuando acceda al siguiente recurso, puede obtener una respuesta de la misma clase de código. Incluso puede haber una larga cadena de redirecciones que, de realizarse de forma automática, crearían una carga excesiva en el equipo. Por lo tanto, los desarrolladores del protocolo HTTP recomiendan encarecidamente que después de la segunda respuesta consecutiva, se solicite al usuario la confirmación de la redirección (anteriormente se recomendaba después de la quinta). El cliente es responsable de monitorear esto, ya que servidor actual puede redirigir al cliente a un recurso en otro servidor. El cliente también debe evitar realizar redireccionamientos circulares. Error de cliente 4xx (ruso) error del cliente) Los códigos 5xx se asignan para casos de funcionamiento fallido debido a un fallo del servidor. Para todas las situaciones distintas al uso del método HEAD, el servidor debe incluir en el cuerpo del mensaje una explicación que el cliente mostrará al usuario.

Encabezamientos

Cuerpo del mensaje

Ejemplos de diálogo HTTP

Solicitud GET regular

Solicitud del cliente:

OBTENER /wiki/ página HTTP/1.1 Host: ru.wikipedia.org Agente de usuario: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Aceptar: text/html Conexión: cerrar

Respuesta del servidor:

HTTP/1.0 200 OK Fecha: miércoles, 11 de febrero de 2009 11:20:59 GMT Servidor: Apache X-Desarrollado por: PHP/5.2.4-2ubuntu5wm1 Última modificación: miércoles, 11 de febrero de 2009 11:20:59 GMT Contenido -Idioma: ru Tipo de contenido: texto/html; charset=utf-8 Longitud del contenido: 1234 Conexión: cerrar (la siguiente es la página solicitada en

Redirecciones

Digamos que la empresa ficticia Ejemplo Corp. hay un sitio principal en http://example.com y un dominio alias example-corp.com. El cliente envía una solicitud para la página Acerca de al dominio secundario (algunos de los encabezados se omiten):

Ubicación: http://www.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; charset=windows-1251 Longitud del contenido: 110 (línea vacía) haga clic aquí

Puede especificar fragmentos en el encabezado Ubicación como en este ejemplo. El navegador no incluyó el fragmento en la solicitud porque está interesado en el documento completo. Pero automáticamente desplazará la página hasta el fragmento de "contactos" tan pronto como la cargue. También se colocó un breve documento HTML con un enlace en el cuerpo de la respuesta, que llevará al visitante a la página de destino si el navegador no accede a ella automáticamente. El encabezado Content-Type contiene las características de esta explicación HTML particular, no el documento que se encuentra en la URL de destino.

Digamos que esta misma empresa Ejemplo Corp. Tiene varias oficinas regionales en todo el mundo. Y para cada oficina de representación tienen un sitio web con el ccTLD correspondiente. Pedido pagina de inicio El sitio principal example.com podría verse así:

/ HTTP/1.1 Host: www.example.com Agente de usuario: MyLonelyBrowser/5.0 Aceptar: text/html,application/xhtml+xml,application/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-Language y generó una respuesta con una redirección temporal al servidor ruso ejemplo.ru, indicando su dirección en el encabezado Ubicación:

HTTP/1.x 302 encontrado Ubicación: http://www.example.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; charset=windows-1251 Longitud del contenido: 82 (línea vacía) Ejemplo Corp. Rusia

Observe el encabezado Cache-Control. El valor "privado" indica a otros servidores (principalmente servidores proxy) que la respuesta se puede almacenar en caché en el lado del cliente. De lo contrario, es posible que los visitantes posteriores de otros países se dirijan siempre a otra oficina de representación.

Los códigos de respuesta (Ver otros) y (Redireccionamiento temporal) también se utilizan para la redirección.

Reanudación y descarga fragmentaria

Digamos que una organización ficticia ofrece descargar un vídeo de un sitio web. última conferencia en http://example.org/conf-2009.avi con un volumen aproximado de 160 MB. Veamos cómo se descarga este archivo en caso de falla y cómo el administrador de descargas organizaría la descarga multiproceso de varios fragmentos.

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

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

El encabezado Referer indica que el archivo fue solicitado desde la página de inicio del sitio. Los gestores de descargas también suelen indicarlo para poder emular una transición desde una página web. Sin él, el servidor puede responder (Acceso prohibido) si no se permiten solicitudes de otros sitios. En nuestro caso, el servidor arrojó una respuesta exitosa:

HTTP/1.1 200 OK 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 ETag: "56d-9989200-1132c580" Contenido -Tipo: vídeo/x-msvideo Longitud del contenido: 160993792 Rangos de aceptación: bytes Conexión: cerrar (línea vacía) (contenido binario de todo el archivo)

El encabezado Accept-Ranges informa al cliente que puede solicitar fragmentos del servidor, indicando sus desplazamientos desde el principio del archivo en bytes. Si falta este encabezado, el cliente puede advertir al usuario que lo más probable es que no sea posible descargar el archivo. 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 hilos. Si el servidor no especifica el tamaño, entonces el cliente no podrá implementar la descarga paralela, pero al mismo tiempo podrá continuar descargando el archivo hasta que el servidor responda (rango solicitado no satisfecho).

Digamos que a los 84 megas se interrumpió la conexión a Internet y se pausó el proceso de descarga. Cuando se restableció la conexión a Internet, el navegador envió automáticamente nueva solicitud al servidor, pero con instrucciones para generar el contenido del megabyte 84:

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

No se requiere que el servidor recuerde qué y de quién fueron las solicitudes anteriores, por lo que el cliente reinsertó el encabezado Referer como si fuera su primera solicitud. El valor especificado del encabezado Range le dice al servidor que "entregue el contenido desde el byte 88080384 hasta el final". En este sentido, el servidor devolverá la siguiente 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 ETag: "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 (línea vacía) (contenido binario a partir de 84 megabytes)

El encabezado Accept-Ranges ya no es necesario aquí, ya que el cliente ya conoce esta capacidad del servidor. El cliente se entera de que el código está transmitiendo un fragmento (contenido parcial). El encabezado Content-Range contiene información sobre este fragmento: números de los bytes iniciales y finales, y después de la barra diagonal, el tamaño total de todo el archivo 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-Length contendrá 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 cargará el inicial en la primera solicitud, interrumpiendo la conexión tan pronto como llegue al inicio de la segunda. El resto lo solicitará por separado. Por ejemplo, la cuarta sección se solicitará con los siguientes encabezados (algunos de los encabezados se omiten; consulte el ejemplo completo arriba):

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

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

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

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

Consulte también rangos de bytes, respuesta 406, respuesta 416.

Mecanismos de protocolo básico

GET parciales

HTTP le permite solicitar no todo el contenido de un recurso a la vez, sino solo un fragmento específico. Estas solicitudes se denominan GET parciales, la capacidad de ejecutarlos es opcional (pero deseable) para los servidores. Los GET parciales se utilizan principalmente para reanudar archivos y descargas paralelas rápidas en múltiples subprocesos. Algunos programas descargan el encabezado del archivo y lo muestran al usuario. estructura interna 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 Range, indicando en él lo necesario rangos de bytes. Si el servidor no comprende las solicitudes parciales (ignora el encabezado Range), devolverá el contenido completo con el estado, como con un GET normal. Si tiene éxito, el servidor devuelve una respuesta con el estado 206 (Contenido parcial) en lugar del código 200, incluido el encabezado Content-Range en la respuesta. Los propios fragmentos se pueden transmitir de dos formas:

Ver también.

OBTENER condicional

Negociación de contenidos

Negociación de contenidos(Inglés) Negociación de contenidos) - mecanismo detección automática recurso necesario cuando existen varios tipos diferentes de versiones de documentos. Los temas de coordinación pueden ser no solo los recursos del servidor, sino también las páginas devueltas con mensajes de error (, etc.).

Hay dos tipos principales de aprobaciones:

Administrado por servidor(Inglés) Impulsado por servidor).
Impulsado por el cliente(Inglés) Impulsado por agentes).

Se pueden utilizar simultáneamente ambos tipos o cada uno de ellos por separado.

La especificación del protocolo principal (RFC 2616) también destaca el llamado aprobación transparente(Inglés) Negociación transparente) como la opción preferida para combinar ambos tipos. Este último mecanismo no debe confundirse con la tecnología independiente. Negociación de contenidos transparente (TCN, ruso Negociación de contenidos transparente , consulte RFC 2295), que no forma parte del protocolo HTTP, pero se puede utilizar con él. Ambos tienen diferencias significativas 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 producir la que crea que es la versión más adecuada. Las principales cabeceras analizadas son Accept, Accept-Charset, Accept-Encoding, Accept-Languages y User-Agent. Es recomendable que el servidor incluya un encabezado Vary en la respuesta indicando los parámetros por los cuales difiere el contenido del URI solicitado.

La ubicación geográfica del cliente puede ser determinada por la dirección IP remota.

La negociación basada en servidor tiene varias desventajas:

El servidor sólo adivina qué opción es más preferible para el usuario final, pero no puede saber exactamente qué se necesita en en este momento(por ejemplo, versión en ruso o inglés).
Se envían muchos encabezados de grupo Aceptar, pero pocos recursos con múltiples opciones. Debido a esto, el equipo sufre una carga excesiva.
La caché compartida tiene una capacidad limitada para producir la misma respuesta a solicitudes idénticas de diferentes usuarios.
Pasar encabezados Aceptar también compromete la privacidad del usuario al revelar cierta información sobre sus preferencias.

Impulsado por el cliente

EN en este caso el tipo de contenido se determina sólo en el lado del cliente. Para ello, el servidor devuelve con el código de estado 300 (Múltiples opciones) o 406 (No aceptable) una lista de opciones entre las que el usuario selecciona la adecuada. La conciliación impulsada por el cliente es buena cuando el contenido varía en formas comunes (como el idioma y la codificación) y se utiliza un caché público. La principal desventaja: carga extra, ya que hay que realizar una solicitud adicional para obtener el contenido deseado.

Aprobación transparente

Esta negociación es completamente transparente para el cliente y el servidor. En este caso, se utiliza una caché compartida que contiene una lista de opciones, similar a la negociación dirigida por el cliente. Si el caché comprende todas estas opciones, entonces él mismo toma la decisión, como en la negociación impulsada por el servidor. Esto reduce la carga en el servidor de origen y elimina la solicitud adicional del cliente.

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

Múltiples contenidos

Artículo principal: jerarquías con anidamiento de elementos entre sí. Los tipos de medios multipart/* se utilizan para indicar contenido múltiple. Trabajar con tales tipos se lleva a cabo utilizando reglas generales como se describe en RFC 2046 (a menos que un tipo de medio específico especifique lo contrario). Si el destinatario no sabe cómo manejar el tipo, lo trata de la misma manera que multipart/mixed.

En el lado del servidor, se pueden enviar mensajes con múltiples contenidos en respuesta a al solicitar varios fragmentos de un recurso. En este caso, se utiliza el tipo de medio multipart/byteranges.

HTTP es un protocolo para transferir hipertexto entre sistemas distribuidos. Básicamente, http es el elemento fundamental. Web moderna. Como desarrolladores web que nos preciemos, deberíamos saber todo lo posible al respecto.

Miremos este protocolo a través del lente de nuestra profesión. En la primera parte, repasaremos los conceptos básicos y veremos las solicitudes/respuestas. En el próximo artículo veremos funciones más detalladas, como el almacenamiento en caché, el procesamiento de conexiones y la autenticación.

También en este artículo me referiré principalmente al estándar RFC 2616: Protocolo de transferencia de hipertexto - HTTP/1.1.

Conceptos básicos de HTTP

HTTP permite la comunicación entre múltiples hosts y clientes y admite una variedad de configuraciones de red.

Básicamente, TCP/IP se utiliza para la comunicación, pero este no es el único. opción posible. De forma predeterminada, TCP/IP utiliza el puerto 80, pero se pueden utilizar otros.

La comunicación entre el anfitrión y el cliente se produce en dos etapas: solicitud y respuesta. El cliente genera una solicitud HTTP, en respuesta a la cual el servidor proporciona una respuesta (mensaje). Un poco más adelante veremos este esquema de trabajo con más detalle.

La versión actual del protocolo HTTP es la 1.1, en la que se han introducido algunas características nuevas. En mi opinión, los más importantes son: soporte para una conexión constantemente abierta, nuevo mecanismo transferencia de datos, codificación de transferencia fragmentada, nuevos encabezados para almacenamiento en caché. Veremos algo de esto en la segunda parte de este artículo.

URL

El núcleo de la comunicación web es la solicitud, que se envía a través del Localizador uniforme de recursos (URL). Estoy seguro de que ya sabes qué es una URL, pero para estar completo, decidí decir algunas palabras. La estructura de la URL es muy simple y consta de los siguientes componentes:

El protocolo puede ser http para conexiones regulares o https para un intercambio de datos más seguro. El puerto predeterminado es 80. A esto le sigue la ruta al recurso en el servidor y una cadena de parámetros.

Métodos

Usando una URL, definimos el nombre exacto del host con el que queremos comunicarnos, pero la acción que debemos realizar solo se puede comunicar usando el método HTTP. Por supuesto, hay varios tipos de acciones que podemos realizar. HTTP implementa los más necesarios, adecuados para las necesidades de la mayoría de las aplicaciones.

Métodos existentes:

CONSEGUIR: accede a un recurso existente. La URL enumera toda la información necesaria para que el servidor pueda encontrar y devolver el recurso solicitado como respuesta.

CORREO: Se utiliza para crear un nuevo recurso. Solicitud de publicación normalmente contiene todo información necesaria para crear un nuevo recurso.

PONER: actualiza el recurso actual. La solicitud PUT contiene los datos que se actualizarán.

BORRAR: Se utiliza para eliminar un recurso existente.

Estos métodos son los más populares y los más utilizados. varios instrumentos y marcos. En algunos casos, las solicitudes PUT y DELETE se envían mediante el envío de un POST, cuyo contenido indica la acción a realizar sobre el recurso: crear, actualizar o eliminar.

HTTP también admite otros métodos:

CABEZA: Similar a OBTENER. La diferencia es que con este tipo de solicitud no se transmite ningún mensaje. El servidor sólo recibe los encabezados. Se utiliza, por ejemplo, para determinar si un recurso ha sido modificado.

RASTRO: durante la transmisión, la solicitud pasa por muchos puntos de acceso y servidores proxy, cada uno de los cuales ingresa su propia información: IP, DNS. Con este método, puede ver toda la información intermedia.

OPCIONES: Se utiliza para determinar las capacidades, los ajustes y la configuración del servidor para un recurso específico.

Códigos de estado

En respuesta a una solicitud del cliente, el servidor envía una respuesta, que también contiene un código de estado. Este código tiene un significado especial para que el cliente pueda entender más claramente cómo interpretar la respuesta:

1xx: mensajes informativos

Un conjunto de estos códigos se introdujo en HTTP/1.1. El servidor puede enviar una solicitud del formulario: Esperar: 100-continuar, lo que significa que el cliente todavía está enviando el resto de la solicitud. Los clientes que ejecutan HTTP/1.0 ignoran estos encabezados.

2xx: mensajes de éxito

Si el cliente recibió un código de la serie 2xx, entonces la solicitud se envió correctamente. La opción más común es 200 OK. Con una solicitud GET, el servidor envía una respuesta en el cuerpo del mensaje. También hay otras posibles respuestas:

202 Aceptado: Se acepta la solicitud, pero puede no contener el recurso en la respuesta. Esto es útil para solicitudes asincrónicas en el lado del servidor. El servidor determina si enviar el recurso o no.
204 Sin contenido: No hay ningún mensaje en el cuerpo de la respuesta.
205 Restablecer contenido: Indica al servidor que restablezca la presentación del documento.
206 Contenido parcial: La respuesta contiene solo una parte del contenido. Los encabezados adicionales determinan la longitud total del contenido y otra información.

3xx: redireccionamiento

Una especie de mensaje al cliente sobre la necesidad de realizar una acción más. El caso de uso más común es redirigir al cliente a otra dirección.

301 movido permanentemente: el recurso ahora se puede encontrar de forma diferente dirección URL.
303 Ver Otros: El recurso se puede encontrar temporalmente en una URL diferente. El encabezado Ubicación contiene una URL temporal.
304 No modificado: El servidor determina que el recurso no se ha modificado y el cliente necesita utilizar la versión almacenada en caché de la respuesta. Para comprobar la identidad de la información, se utiliza ETag (Entity Tag hash);

4xx: errores del cliente

El servidor utiliza esta clase de mensaje si decide que la solicitud se envió por error. El código más común es 404 No encontrado. Esto significa que el recurso no se encontró en el servidor. Otros códigos posibles:

400 Solicitud incorrecta : La pregunta se formuló incorrectamente.
401 no autorizado: Se requiere autenticación para realizar una solicitud. La información se transmite a través del encabezado Autorización.
403 Prohibido: El servidor no permitió el acceso al recurso.
Método 405 no permitido: Se utilizó un método HTTP no válido para acceder al recurso.
409 Conflicto: el servidor no puede procesar completamente la solicitud porque intenta cambiar una versión más nueva de un recurso. Esto sucede a menudo con las solicitudes PUT.

5xx: errores del servidor

Una serie de códigos que se utilizan para detectar un error del servidor al procesar una solicitud. El más común: Error 500 interno del servidor. Otras opciones:

501 no implementado: El servidor no admite la funcionalidad solicitada.
Servicio 503 no disponible: Esto puede suceder si el servidor tiene un error o está sobrecargado. Generalmente en este caso, el servidor no responde y el tiempo dado para la respuesta expira.

Formatos de mensajes de solicitud/respuesta

En la siguiente imagen puede ver un proceso esquemático de envío de una solicitud por parte del cliente, procesamiento y envío de una respuesta por parte del servidor.

Veamos la estructura. mensaje transmitido vía HTTP:

Mensaje = *() CRLF [ ] = Línea de solicitud | Línea de estado = Nombre-campo ":" Valor-campo

Debe haber una línea en blanco entre el encabezado y el cuerpo del mensaje. Puede haber varios títulos:

El cuerpo de la respuesta puede contener toda o parte de la información si la función correspondiente está habilitada (Codificación de transferencia: fragmentada). HTTP/1.1 también admite el encabezado Transfer-Encoding.

Títulos generales

A continuación se muestran varios tipos de encabezados que se utilizan tanto en solicitudes como en respuestas:

Ya hemos cubierto algunas cosas en este artículo, algunas las discutiremos con más detalle en la segunda parte.

El encabezado via se utiliza en una solicitud TRACE y todos los servidores proxy lo actualizan.

El encabezado Pragma se utiliza para enumerar encabezados personalizados. Por ejemplo, Pragma: no-cache es lo mismo que Cache-Control: no-cache. Hablaremos más sobre esto en la segunda parte.

El encabezado Fecha se utiliza para almacenar la fecha y hora de la solicitud/respuesta.

El encabezado Upgrade se utiliza para cambiar el protocolo.

Transfer-Encoding está destinado a dividir la respuesta en varios fragmentos utilizando Transfer-Encoding: fragmentado. Esta es una característica nueva en HTTP/1.1.

Encabezados de entidad

Los encabezados de entidad transmiten metainformación sobre el contenido:

Todos los encabezados con el prefijo Contenido proporcionan información sobre la estructura, codificación y tamaño del cuerpo del mensaje.

El encabezado Expires contiene la fecha y hora de vencimiento de la entidad. El valor “nunca caduca” significa tiempo + 1 código s momento actual. La última modificación contiene hora y fecha último cambio esencia.

Usando estos encabezados, puede especificar la información necesaria para sus tareas.

Formato de solicitud

La solicitud se parece a esto:

SP es el separador entre tokens. La versión HTTP se especifica en Versión HTTP. La solicitud real se ve así:

OBTENER /articles/http-basics HTTP/1.1 Host: www.articles.com Conexión: keep-alive Control de caché: sin caché Pragma: sin caché Aceptar: texto/html,aplicación/xhtml+xml,aplicación/xml; q=0,9,*/*;q=0,8

Lista de posibles encabezados de solicitud:

El encabezado Aceptar especifica los tipos mime, el idioma y la codificación de caracteres admitidos. Los encabezados De, Host, Referer y User-Agent contienen información sobre el cliente. Los prefijos If- están destinados a crear condiciones. Si la condición no se cumple, se producirá un error 304 No modificado.

Formato de respuesta

El formato de respuesta sólo se diferencia en el estado y en el número de encabezados. El estado se ve así:

Línea de estado = Versión HTTP SP Código de estado SP Frase de motivo CRLF

versión HTTP
Código de estado
Mensaje de estado legible por humanos

El estado normal se parece a esto:

HTTP/1.1 200 correcto

Los encabezados de respuesta pueden ser los siguientes:

La edad es el tiempo en segundos en que se creó el mensaje en el servidor.
Entidades ETag MD5 para verificar cambios y modificaciones en la respuesta.
La ubicación se utiliza para la redirección y contiene la nueva URL.
Servidor especifica el servidor donde se generó la respuesta.

Creo que es suficiente teoría por hoy. Ahora echemos un vistazo a las herramientas que podemos usar para monitorear mensajes HTTP.

Herramientas para detectar tráfico HTTP

Existen muchas herramientas para monitorear el tráfico HTTP. Éstos son algunos de ellos:

El más utilizado son las herramientas para desarrolladores de Chrome:

Si hablamos de un depurador, puedes usar Fiddler:

Para Seguimiento HTTP tráfico necesitarás curl, tcpdump y tshark.

Bibliotecas para trabajar con HTTP - jQuery AJAX

Dado que jQuery es tan popular, también tiene herramientas para manejar respuestas HTTP para solicitudes AJAX. Puede encontrar información sobre jQuery.ajax (configuración) en el sitio web oficial.

Al pasar un objeto de configuración y usar la función de devolución de llamada beforeSend, podemos configurar los encabezados de solicitud usando el método setRequestHeader().

$.ajax(( url: "http://www.articles.com/latest", escriba: "GET", beforeSend: function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); ) ));

Si desea procesar el estado de la solicitud, puede hacerlo así:

$.ajax(( código de estado: ( 404: función() (alerta("página no encontrada"); ) ) ));

En pocas palabras

Aquí está, un recorrido por los conceptos básicos del protocolo HTTP. Habrá aún más en la segunda parte. hechos interesantes y ejemplos.

En el corazón de la web se encuentra el Protocolo de transferencia de hipertexto (HTTP), que es un nivel de aplicación. Las descripciones de HTTP se pueden encontrar en RFC 1945 y RFC 2616. El protocolo HTTP se implementa mediante dos programas: un cliente y un servidor que, ubicados en diferentes sistemas finales, intercambian mensajes HTTP. El orden de intercambio y el contenido de los mensajes se describen en el protocolo. Antes de sumergirnos en HTTP, primero comprendamos la terminología utilizada en el contexto web.

Cada página web o documento se compone de objetos. Un objeto es un archivo HTML normal, una imagen JPEG o GIF, un subprograma de Java, un clip de audio, etc., es decir, una entidad que tiene su propio localizador uniforme de recursos (URL). Normalmente, las páginas web constan de un archivo HTML base y los objetos a los que enlaza. Entonces, si una página web incluye un archivo HTML básico y cinco imágenes, entonces consta de seis objetos. Los enlaces de objetos relacionados con una página web son URL incluidas en el archivo HTML subyacente. Una URL consta de dos partes: el nombre de host del servidor en el que se encuentra el objeto y la ruta al objeto. Entonces, por ejemplo, para la URL _www.someSchool.edu/someDepartment/picture.gif, el nombre de host es el fragmento _www.someSchool.edu y la ruta al objeto es el fragmento someDepartment/picture.gif.

El agente de usuario web se llama navegador; muestra páginas web y también realiza muchas funciones de utilidad adicionales. Además, los navegadores representan el lado cliente del protocolo HTTP. Así, los términos “navegador” y “cliente” en el contexto web se utilizarán como equivalentes. Algunos de los navegadores más populares incluyen Netscape Navigator y internet Explorador.

El servidor web contiene objetos, cada uno de los cuales se identifica por su URL. Además, los servidores web representan el lado del servidor del protocolo HTTP. Los servidores web más populares incluyen Apache y Microsoft Internet Information Server.

El protocolo HTTP define cómo los clientes (como los navegadores) solicitan páginas web y cómo los servidores entregan esas páginas. Hablaremos con más detalle sobre la interacción entre el cliente y el servidor más adelante, pero la idea básica se puede entender en la Fig. 2.4. Cuando un usuario solicita una página web (por ejemplo, hace clic en un hipervínculo), el navegador envía una solicitud HTTP al servidor para los objetos que componen la página web. El servidor recibe la solicitud y envía mensajes de respuesta que contienen los objetos requeridos. En 1997, prácticamente todos los navegadores y servidores web comenzaron a admitir la versión 1.0 de HTTP, descrita en RFC 1945. En 1998, comenzó la transición a la versión 1.1, que se describió en RFC 2616. La versión 1.1 ha compatible con versiones anteriores con la versión 1.0, es decir, cualquier servidor o navegador que utilice la versión 1.1 puede interactuar completamente con un navegador o servidor que admita la versión 1.0.

Tanto HTTP 1.0 como HTTP 1.1 utilizan TCP como protocolo capa de transporte. Un cliente HTTP primero establece una conexión TCP con el servidor y, una vez creada la conexión, el cliente y el servidor comienzan a comunicarse con el protocolo TCP a través de una interfaz de socket. Como se indicó anteriormente, los sockets son "puertas" entre los procesos y el protocolo de la capa de transporte.

El cliente envía solicitudes y recibe respuestas a través de su interfaz de socket, y el servidor usa la interfaz de socket para recibir solicitudes y ejecutarlas. Una vez que la solicitud web pasa por el socket del cliente, queda en manos del protocolo TCP. Recordemos que una de las funciones del protocolo TCP es asegurar una transmisión de datos confiable; esto significa que cada solicitud enviada por el cliente y cada respuesta del servidor se entrega exactamente como se envió. Aquí es donde se manifiesta una de las ventajas del modelo de comunicación multicapa: el protocolo HTTP no necesita monitorear la confiabilidad de la transmisión y garantizar que los paquetes se retransmitan en caso de corrupción. Todo el trabajo "sucio" lo realizará el protocolo TCP y los protocolos de nivel inferior.

Cabe señalar que una vez finalizado el servicio a los clientes, el servidor no almacena ninguna información sobre ellos. Si, por ejemplo, un cliente realiza dos solicitudes seguidas para el mismo recurso, el servidor las cumplirá sin notificar al cliente sobre la solicitud duplicada. Se dice que el protocolo HTTP es un protocolo sin estado para conexiones.

El protocolo HTTP o Protocolo de Transferencia de Hipertexto es el protocolo principal (de la World Wide Web). La tarea principal del protocolo es garantizar la transmisión de hipertexto a través de la red. El protocolo describe con precisión el formato de mensaje para el intercambio de clientes y servidores.

El protocolo HTTP se describe en RFC 2616 (HTTP1.1).

La base del protocolo es garantizar la interacción entre el cliente y el servidor mediante una solicitud ASCII y la siguiente respuesta en el estándar RFC 822 MIME.

En la práctica, el protocolo HTTP opera en el puerto 80, pero se puede configurar de manera diferente. Y aunque TCP/IP no es obligatorio, sigue siendo preferible, ya que se encarga de dividir y ensamblar mensajes y no "carga" ni al navegador ni al servidor.

Cabe señalar que el protocolo HTTP se puede utilizar no solo en tecnologías web, sino también en otras aplicaciones orientadas a objetivos.

URL

La base de la comunicación web cliente-servidor es la solicitud. La solicitud se envía cuando URL de ayuda– un índice unificado de recursos de Internet. Déjame recordarte qué es una URL.

Claro y sencillo estructura de URL consta de los siguientes elementos:

Protocolo;
Anfitrión;
Puerto;
Directorio de recursos;
Etiquetas (Consulta).

Nota: El protocolo http es un protocolo para conexiones simples y no seguras. Las conexiones seguras funcionan a través de protocolo https. Es más seguro para el intercambio de datos.

Métodos de solicitud HTTP

uno de Parámetros de URL, especifica el nombre del host con el que queremos comunicarnos. Pero esto no es suficiente. Es necesario determinar la acción a tomar. Esto se puede hacer usando el método definido por el protocolo HTTP.

Métodos HTTP

Método/Descripción
HEAD/Leer el título de la página web
OBTENER/Leer página web
PUBLICAR/Agregar a la página web
PONER/Guardar página web
TRACE/Solicitud de devolución
BORRAR/Eliminar una página web
OPCIONES/Opciones de visualización
CONECTAR/Reservado para uso futuro

Veamos los métodos HTTP con más detalle.

OBTENER método. solicita una página (archivo, objeto) codificada utilizando el estándar MIME. Este es el método más utilizado. Estructura del método:
OBTENER nombre de archivo HTTP/1.1

Método CABEZA. Este método solicita el encabezado del mensaje. Sin embargo, la página no se carga. Este método le permite saber la hora. última actualización páginas, que es necesario para administrar el caché de la página. Este método le permite verificar la funcionalidad de la URL solicitada.

Método PUESTA. Este método puede colocar la página en el servidor. El cuerpo de la solicitud PUT incluye la página que se alojará, que está codificada en MIME. Este método requiere la identificación del cliente.

Método POST. Este método agrega contenido a una página existente. Se utiliza como ejemplo para agregar una publicación a un foro.

Método BORRAR. Este método destruye la página. El método de eliminación requiere la confirmación de los derechos del usuario para eliminar.

Método TRACE. Este es un método de depuración. Le dice al servidor que devuelva la solicitud y le permite saber si la solicitud del cliente está dañada o no cuando regresa del servidor.

método CONECTAR– método de reserva, no utilizado.

Método de opciones le permite consultar las propiedades del servidor y las propiedades de cualquier archivo.

En la comunicación solicitud-respuesta entre el cliente y el servidor, el servidor necesariamente genera una respuesta. Podría ser una página web o una barra de estado con un código de estado. Conoces bien el código de estado. Uno de los códigos es el conocido código 404 – Página no encontrada.

Grupos de códigos de estado

1хх: Preparación del servidor, Código 100: el servidor está listo para procesar las solicitudes de los clientes;

2xx: Éxito.

Código 200: la solicitud se procesó con éxito;
Código 204 – Sin contenido.

3xx: Redirección.

Código 301: la página solicitada se ha movido;
Código 304: la página en el caché sigue siendo relevante.

4xx: error del cliente.

Todos los datos dentro de la tecnología web se transmiten a través del protocolo. HTTP(Protocolo de transferencia de hipertexto). La excepción es el intercambio mediante programación Java o el intercambio desde aplicaciones complementarias. Teniendo en cuenta el volumen real de tráfico que se transmite como parte de un intercambio web a través de HTTP, sólo consideraremos este protocolo. Al hacerlo, consideraremos preguntas como:

Estructura general del mensaje

HTTP es un protocolo de capa de aplicación. El protocolo se centra en el modelo de intercambio cliente-servidor. El intercambio se lleva a cabo en fragmentos de datos llamados mensajes HTTP. Los mensajes enviados del cliente al servidor se denominan solicitudes y los mensajes enviados del servidor al cliente se denominan respuestas. Un mensaje puede constar de dos partes: un encabezado y un cuerpo. El cuerpo está separado del encabezado por una línea en blanco.

El encabezado contiene información de servicio necesaria para procesar el cuerpo del mensaje o controlar el intercambio. El encabezado consta de directivas de encabezado, que generalmente se escriben cada una en una nueva línea.

El cuerpo del mensaje es opcional, pero el encabezado del mensaje sí lo es. Puede contener información de texto, gráficos, audio o vídeo.

A continuación se muestra la solicitud HTTP:

OBTENER / HTTP/1.0 Aceptar: imagen/jpeg [línea en blanco]

y respuesta:

HTTP/1.0 200 OK Fecha: viernes, 24 de julio de 1998 21:30:51 GMT Servidor: Apache/1.2.5 Tipo de contenido: texto/html Longitud del contenido: 21345 [línea en blanco] contexto de la página

El texto de "línea en blanco" es simplemente para indicar disponibilidad. linea vacia, que separa el encabezado del mensaje HTTP de su cuerpo.

El servidor, al recibir una solicitud de un cliente, convierte parte de la información del encabezado de la solicitud HTTP en variables de entorno, que están disponibles para su análisis mediante un script CGI. Si la solicitud tiene un cuerpo, entonces el cuerpo se pone a disposición del script a través del flujo de entrada estándar.

Métodos de acceso

La directiva más importante de una solicitud HTTP es el método de acceso. Se indica como la primera palabra en la primera línea de la consulta. En nuestro ejemplo esto es GET. Hay cuatro métodos de acceso principales:

Además de estos cuatro métodos, existen alrededor de cinco métodos de acceso adicionales, pero rara vez se implementan en la práctica.

OBTENER método

El cliente utiliza el método GET al realizar una solicitud al servidor de forma predeterminada. Con este método, el cliente comunica la dirección del recurso (URL) que desea recibir, la versión del protocolo HTTP, los tipos de documentos MIME que admite y la versión y nombre del software del cliente. Todos estos parámetros se especifican en el encabezado de la solicitud HTTP. El cuerpo no se envía en la solicitud.

En respuesta, el servidor informa la versión del protocolo HTTP, el código de retorno, el tipo de contenido del cuerpo del mensaje, el tamaño del cuerpo del mensaje y una serie de otras directivas de encabezado HTTP opcionales. El recurso en sí, normalmente una página HTML, se envía en el cuerpo de la respuesta.

método CABEZA

El método HEAD se utiliza para minimizar los intercambios cuando se trabaja con el protocolo HTTP. Es similar al método GET excepto que el cuerpo del mensaje no se envía en la respuesta. Este método se utiliza para verificar la hora de la última modificación de un recurso, para verificar la fecha de vencimiento de los recursos almacenados en caché, cuando se utilizan programas de escaneo de recursos mundiales. Amplia red. En resumen, el método HEAD está diseñado para minimizar la cantidad de información transmitida a través de la red como parte de un intercambio HTTP.

método POST

El método POST es una alternativa al método GET. Al intercambiar datos mediante el método POST, la solicitud del cliente contiene un cuerpo de mensaje HTTP. Este cuerpo se puede formar a partir de datos ingresados en un formulario HTML o de un archivo externo adjunto. La respuesta suele contener tanto el encabezado como el cuerpo del mensaje HTTP. Para iniciar un intercambio utilizando el método POST en el atributo método recipiente forma se debe especificar el valor "publicación".

método poner

El método PUT se utiliza para publicar páginas HTML en el directorio del servidor HTTP. Al transmitir datos de un cliente a un servidor, el mensaje contiene un encabezado de mensaje, que indica la URL del recurso, y un cuerpo, el contenido del recurso alojado.

Por lo general, la respuesta no envía el cuerpo del recurso, sino que contiene un código de retorno en el encabezado del mensaje que determina si la asignación del recurso fue exitosa o no.

Optimización del intercambio

El protocolo HTTP fue diseñado originalmente para ser un protocolo sin conexión. Esto significa que una vez que el servidor acepta una solicitud del cliente y responde a ella, la conexión entre el cliente y el servidor se pierde. Para un nuevo intercambio de datos, se debe establecer una nueva conexión. Este enfoque tiene ventajas y desventajas.

Las ventajas incluyen la capacidad de dar servicio simultáneamente a una gran cantidad de consultas cortas. Incluso en servidores populares, la cantidad de conexiones abiertas no puede exceder los cientos cuando se atiende alrededor de un millón de solicitudes por día. En este caso, un cliente puede abrir hasta 40 conexiones simultáneamente, que desde el punto de vista del servidor son iguales. Con líneas de comunicación de alta velocidad, esto permite lograr un tiempo de respuesta corto a la solicitud de un cliente para toda la página (texto, gráficos, etc.).

Las desventajas de este esquema de intercambio incluyen: la necesidad de establecer una conexión para cada intercambio y la imposibilidad de mantener una sesión de trabajo con un recurso de información. Al inicializar una conexión mediante protocolo de transporte TCP y la terminación de esta conexión requieren transferir una cantidad bastante grande de información de servicio. La falta de soporte de sesión en HTTP complica significativamente el trabajo con recursos como bases de datos o recursos que requieren autenticación.

Para optimizar el número abrir conexiones TCP Las versiones 1.0 y 1.1 del protocolo HTTP proporcionan el modo de mantenimiento de actividad. En este modo, la conexión se inicializa una sola vez y se pueden realizar varios intercambios HTTP de forma secuencial.

Para implementar el soporte de sesión, se agregaron "cookies" a las directivas del encabezado HTTP. Le permiten simular el soporte de conexión cuando trabaja con el protocolo HTTP.

Codificación de solicitudes GET y POST.

Hay dos tipos de codificación de solicitudes HTTP. Básico - codificado en URL, también conocido como - codificación estándar URL. El espacio se representa como %20, las letras rusas y la mayoría de los caracteres especiales están codificados, las letras y guiones en inglés se dejan como están.

La forma en que se deben codificar los datos del formulario cuando se envían se especifica en su etiqueta HTML:

// OBTENER método con codificación predeterminada // enctype establece explícitamente la codificación // Método POST con codificación predeterminada (codificada en URL, como el formulario anterior)

Si el formulario se envía de la forma habitual, entonces el propio navegador codifica (código de URL) el nombre y el valor de cada campo de datos (entrada, etc.) y envía el formulario al servidor en formato codificado.

El segundo método de codificación es sin codificación. Por ejemplo, no se necesita codificación para transferir archivos. Se especifica en el formulario (solo para POST) así:

En este caso, no se codifica nada al enviar datos al servidor. Y el servidor, por su parte, mirando “Content-Type: multipart/form-data” entenderá lo que ha llegado.

Codificación de datos.

Si solo usa UTF-8, no necesita esta sección.

Todos los parámetros GET/POST que van al servidor, excepto en el caso de datos multiparte/formulario, están codificados en UTF-8. No en la codificación de la página, sino en UTF-8. Por lo tanto, por ejemplo, en PHP es necesario recodificarlos con la función iconv si es necesario.

$nombre = iconv("UTF8","CP1251",$_GET["nombre"]);

El navegador recibe la respuesta del servidor exactamente en la codificación especificada en el encabezado de respuesta Content-Type. Es decir, nuevamente, en PHP, para que el navegador acepte la respuesta en Windows-1251 y normalmente muestre los datos en la página en Windows-1251, debe enviar un encabezado codificado en código PHP, por ejemplo así:

Encabezado("Tipo de contenido: texto/sin formato; conjunto de caracteres=windows-1251");

O bien, el servidor debe agregar dicho encabezado. Por ejemplo, en apache la codificación se agrega automáticamente con la opción:

# en la configuración de Apache AddDefaultCharset windows-1251
.

Popular en la categoría: