Hogar › Tarifas › Los métodos de solicitud HTTP incluyen: En términos simples sobre HTTP. Veamos los métodos HTTP con más detalle.

Los métodos de solicitud HTTP incluyen: En términos simples sobre HTTP. Veamos los métodos HTTP con más detalle.

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 una solución tareas específicas 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

Uso formato de texto en el protocolo da lugar al correspondiente inconveniente: gran tamaño mensajes versus transmisión 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 sobre el 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 diseñado como un medio para trabajar con los recursos del servidor, no proporciona explícitamente un medio para navegar entre estos recursos. Por ejemplo, un cliente no puede solicitar explícitamente una lista archivos disponibles, como en . Se supuso que el usuario final ya conocía los hipervínculos. Esto es bastante normal y conveniente para una persona, pero es difícil cuando hay tareas. procesamiento automático y análisis de 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, lo 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 fue desarrollado originalmente para acceder documentos de hipertexto 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 Download Master son populares en el sistema operativo Windows. Descarga gratuita Gerente, ReGet. 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 determinar las capacidades del servidor web o los parámetros de conexión para un 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. Actualmente no se ha determinado el formato del cuerpo y el procedimiento para trabajar con él. 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 distinguen entre . Las solicitudes GET condicionales contienen Encabezados Si-Modificado-Desde, 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 comentarios en 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 muchas veces puede devolver diferentes resultados(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 es la comprensión del propósito del URI del recurso. método POST asume 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 nueva dirección indicado en el campo Ubicación del encabezado. En este caso, el cliente debe, por regla general, realizar una transición automática (jarl. 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

) La clase de código 4xx está destinada a indicar errores en el lado del cliente. Cuando se utilizan todos los métodos excepto HEAD, el servidor debe devolver una explicación de hipertexto al usuario en el cuerpo del mensaje.

Para recordar los valores de los códigos 400 a 417, existen técnicas mnemotécnicas ilustrativas 5xx Server Error (Russian.

error del servidor

) 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 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 (cadena 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. En el cuerpo de la respuesta también se colocó un breve documento HTML con un enlace, con la ayuda del cual se dirigirá al visitante a página de destino, si el navegador no cambia a él 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 una conferencia anterior desde el sitio web http://example.org/conf-2009.avi con un volumen de aproximadamente 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 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 una nueva solicitud al servidor, pero con instrucciones para devolver el contenido desde el 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. Valor especificado El encabezado Range le dice al servidor "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 usuario final, pero no puedo saber exactamente qué se necesita en este momento (por ejemplo, una 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 un código de estado de 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 múltiples fragmentos de recursos. En este caso, se utiliza el tipo de medio multipart/byteranges.

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 mediante una URL: el localizador uniforme de recursos de Internet. Déjame recordarte qué es una URL.

Una estructura de URL clara y sencilla 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 http s. 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 que se debe tomar. Esto se puede hacer utilizando un 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 va a 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 indica 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.

Protocolo estándar para la transmisión de datos a través de World Wide Web-- esto es HTTP (Protocolo de transferencia de hipertexto). Describe mensajes que se pueden intercambiar entre clientes y servidores. Cada interacción consta de una única solicitud ASCII seguida de una única respuesta, similar a la respuesta estándar RFC 822 MIME. Todos los clientes y todos los servidores deben seguir este protocolo. Está definido en RFC 2616.

Conexiones

La forma habitual de que un navegador se comunique con un servidor es establecer una conexión TCP con el puerto 80 del servidor, aunque este procedimiento no es un requisito formal. El valor de utilizar TCP es que ni los navegadores ni los servidores tienen que preocuparse por pérdidas, duplicaciones, mensajes largos y confirmaciones. Todo esto lo proporciona el protocolo TCP.

En HTTP 1.0, después de establecer una conexión, se enviaba una solicitud a la que se recibía una respuesta. Después de esto, se terminó la conexión TCP. En aquella época, una página web típica estaba formada enteramente por texto HTML y esta forma de interactuar era adecuada. Sin embargo, pasaron varios años y la página contenía muchos íconos, imágenes y otras decoraciones. Obviamente, configurar una conexión TCP para transmitir un solo icono es un desperdicio y demasiado costoso.

Esta consideración llevó a la creación del protocolo HTTP 1.1, que admitía conexiones estables. Esto significaba que era posible establecer una conexión TCP, enviar una solicitud, recibir una respuesta y luego enviar y recibir solicitudes y respuestas adicionales. De esta forma, se redujeron los gastos generales incurridos durante las constantes instalaciones y desconexiones de conexiones. También es posible canalizar solicitudes, es decir, enviar la solicitud 2 incluso antes de que llegue la respuesta a la solicitud 1.

Aunque HTTP fue diseñado específicamente para su uso en tecnologías web, intencionalmente se hizo más general de lo necesario, ya que estaba destinado a su uso futuro en aplicaciones orientadas a objetos. Por este motivo, además de las consultas habituales de la página web, operaciones especiales, llamados métodos. Deben su existencia tecnologías de jabón. Cada solicitud consta de una o más cadenas ASCII, siendo la primera palabra el nombre del método que se llamará. Los métodos integrados se enumeran en la tabla de la Fig. 6. Además de estos métodos generales, diferentes objetos también pueden tener sus propios métodos específicos. Los nombres de los métodos distinguen entre mayúsculas y minúsculas, lo que significa que el método GET existe, pero el método get no.

Figura 6: métodos de solicitud HTTP integrados

El método GET solicita una página del servidor (bajo la cual en caso general objeto implícito, pero en la práctica suele ser solo un archivo) codificado de acuerdo con el estándar MIME. La mayoría de Las solicitudes al servidor se componen de solicitudes GET.

El método HEAD simplemente solicita el encabezado del mensaje, sin la página en sí. Con este método podrás saber la hora. último cambio páginas para recopilar información de índice o simplemente para comprobar la funcionalidad de una URL determinada.

El método PUT es lo opuesto al método GET: no lee, sino que escribe la página. Este método le permite crear un conjunto de páginas web en un servidor remoto. El cuerpo de la solicitud contiene la página. Puede estar codificado en MIME. En este caso, las líneas que siguen al comando PUT pueden incluir varios encabezados, como Content-Type o encabezados de autenticación, que confirman los derechos del suscriptor sobre la operación solicitada.

El método POST es algo similar al método PUT. También contiene una URL, pero en lugar de reemplazar los datos existentes, se "añaden" datos nuevos (en algún momento en un sentido general) a los existentes. Esto podría ser publicar un mensaje en una conferencia o agregar un archivo a tablero electrónico Anuncios de BBS. En la práctica, ni PUT ni POST se utilizan ampliamente.

El método DELETE, como era de esperar, elimina la página. Al igual que con el método PUT, la autenticación y el permiso para realizar esta operación pueden desempeñar aquí un papel especial. Incluso si el usuario tiene permiso para eliminar la página, no hay garantía de que el método DELETE elimine la página, porque incluso si el servidor HTTP remoto está de acuerdo, el archivo en sí no se puede modificar ni mover.

El método TRACE está destinado a la depuración. Le dice al servidor que devuelva la solicitud. Este método es especialmente útil cuando las solicitudes no se procesan correctamente y el cliente quiere saber qué tipo de solicitud recibe realmente el servidor.

El método CONNECT no se utiliza actualmente. Está reservado para uso futuro.

El método OPCIONES permite al cliente preguntar al servidor sobre sus propiedades o las propiedades de un archivo específico.

En respuesta a cada solicitud, se recibe una respuesta del servidor que contiene una línea de estado, así como posiblemente información adicional (por ejemplo, la página web o parte de ella). La línea de estado puede contener un código de estado de tres dígitos que indica si la solicitud se realizó correctamente o por qué falló. La primera categoría pretende dividir todas las respuestas en cinco grupos principales, como se muestra en la tabla de la Fig. 7. Los códigos que comienzan con 1 Aхх) rara vez se utilizan en la práctica. Los códigos que comienzan con 2 significan que la solicitud se procesó exitosamente y se enviaron los datos (si se solicitaron). Los códigos 3xx le dicen al cliente que pruebe suerte en otro lugar, ya sea usando una URL diferente o su propio caché.

Figura 7: Grupos de códigos de estado contenidos en las respuestas del servidor

Los códigos que comienzan con 4 significan que la solicitud falló por algún motivo relacionado con el cliente: por ejemplo, se solicitó una página inexistente o la solicitud en sí era incorrecta. Finalmente, los códigos 5xx indican errores del servidor, ya sea por un error del programa o por una sobrecarga temporal.

Ejemplo de uso de HTTP

Dado que HTTP es un protocolo de texto, la interacción con el servidor a través de un terminal (que en este caso actúa como lo contrario de un navegador) se puede organizar de forma muy sencilla. Sólo necesitas establecer una conexión TCP al puerto 80 del servidor. El lector debe ver por sí mismo cómo funciona este script (es preferible ejecutarlo en sistema unix, ya que es posible que algunos otros sistemas no muestren el estado de la conexión). Entonces, la secuencia de comandos es:

Figura 8: secuencia de comandos del protocolo HTTP

Esta secuencia de comandos establece una conexión telnet (es decir, una conexión TCP) al puerto 80 del servidor web del IETF ubicado en www.ietf.org.

El resultado de la sesión de comunicación se registra en un archivo de registro, que luego se puede ver. Luego viene el comando GET. Se indica el nombre del archivo solicitado y el protocolo de transferencia. Luego viene la línea requerida con el encabezado Host. La línea vacía que la sigue también es obligatoria. Le indica al servidor que los encabezados de la solicitud se han agotado. El comando de cierre (este es un comando del programa telnet) cierra la conexión.

El archivo de registro de conexión, log, se puede ver usando cualquier editor de texto. Debería comenzar aproximadamente como se muestra en el listado de la Figura 8, a menos que haya habido algunos cambios en el sitio web del IETF durante este tiempo.

Figura 9 - Inicio de la salida del archivo “www.ietf.org/rfc.html”

Las primeras tres líneas de este listado las genera el programa telnet, no el sitio remoto. Pero la línea que comienza con HTTP/1.1 ya es una respuesta del IETF, lo que indica que el servidor quiere comunicarse con usted mediante el protocolo HTTP/1.1. A esto le sigue una serie de encabezados y, finalmente, el contenido del propio archivo solicitado. Encabezado de etiqueta ET, que es un identificador de página único asociado con el almacenamiento en caché, y X-Pad, un encabezado no estándar que ayuda a combatir los errores del navegador.

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 se forma solicitud HTTP, en respuesta a lo cual el servidor da 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: apoyo constante. conexión abierta, nuevo mecanismo de 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

CON usando URL, definimos el nombre exacto del host con el que queremos comunicarnos, pero la acción que debemos realizar solo se puede comunicar mediante 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. Una solicitud POST normalmente contiene toda la 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 utilizan con mayor frecuencia diversas herramientas y marcos. En algunos casos, las solicitudes PUT y DELETE se envían a través de enviando correo, cuyo contenido indica la acción que se debe realizar con 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. Al usar este método, podrás ver toda la información intermedia.

OPCIONES: Se utiliza para definir 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 tratando de cambiar más nueva versión 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 (Transfer-Encoding: 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. Última modificación contiene la hora y la fecha en que se modificó la entidad por última vez.

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 las opciones admitidas. tipos de mimo, idioma, codificación de caracteres. 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"); ) ) ));