HTTP - Guía rápida

El Protocolo de transferencia de hipertexto (HTTP) es un protocolo a nivel de aplicación para sistemas de información hipermedia distribuidos y colaborativos. Esta es la base para la comunicación de datos para la World Wide Web (es decir, Internet) desde 1990. HTTP es un protocolo genérico y sin estado que se puede utilizar para otros fines, además de utilizar la extensión de sus métodos de solicitud, códigos de error y encabezados.

Básicamente, HTTP es un protocolo de comunicación basado en TCP / IP, que se utiliza para entregar datos (archivos HTML, archivos de imagen, resultados de consultas, etc.) en la World Wide Web. El puerto predeterminado es TCP 80, pero se pueden utilizar otros puertos. Proporciona una forma estandarizada para que las computadoras se comuniquen entre sí. La especificación HTTP especifica cómo se construirán y enviarán los datos de solicitud de los clientes al servidor, y cómo los servidores responderán a estas solicitudes.

Caracteristicas basicas

Existen las siguientes tres características básicas que hacen de HTTP un protocolo simple pero poderoso:

HTTP is connectionless:El cliente HTTP, es decir. El navegador inicia una solicitud HTTP y después de que se realiza una solicitud, el cliente se desconecta del servidor y espera una respuesta. El servidor procesa la solicitud y restablece la conexión con el cliente para devolver la respuesta.
HTTP is media independent:Esto significa que cualquier tipo de datos se pueden enviar por HTTP siempre que tanto el cliente como el servidor sepan cómo manejar el contenido de los datos. Esto es necesario para que el cliente y el servidor especifiquen el tipo de contenido utilizando el tipo MIME apropiado.
HTTP is stateless:Como se mencionó anteriormente, HTTP no tiene conexión y este es un resultado directo de que HTTP es un protocolo sin estado. El servidor y el cliente se conocen entre sí solo durante una solicitud actual. Después, ambos se olvidan el uno del otro. Debido a esta naturaleza del protocolo, ni el cliente ni el navegador pueden retener información entre diferentes solicitudes en las páginas web.

HTTP / 1.0 usa una nueva conexión para cada intercambio de solicitud / respuesta, mientras que la conexión HTTP / 1.1 puede usarse para uno o más intercambios de solicitud / respuesta.

Arquitectura básica

El siguiente diagrama muestra una arquitectura muy básica de una aplicación web y muestra dónde se encuentra HTTP:

El protocolo HTTP es un protocolo de solicitud / respuesta basado en una arquitectura basada en cliente / servidor donde el navegador web, robots y motores de búsqueda, etc. actúan como clientes HTTP y el servidor web actúa como servidor.

Cliente

El cliente HTTP envía una solicitud al servidor en forma de método de solicitud, URI y versión de protocolo, seguida de un mensaje similar a MIME que contiene modificadores de solicitud, información del cliente y posible contenido del cuerpo a través de una conexión TCP / IP.

Servidor

El servidor HTTP responde con una línea de estado, que incluye la versión del protocolo del mensaje y un código de éxito o error, seguido de un mensaje similar a MIME que contiene información del servidor, metainformación de la entidad y posible contenido del cuerpo de la entidad.

Este capítulo enumerará algunos de los parámetros importantes del protocolo HTTP y su sintaxis en la forma en que se utilizan en la comunicación. Por ejemplo, formato de fecha, formato de URL, etc. Esto le ayudará a construir sus mensajes de solicitud y respuesta mientras escribe programas de servidor o cliente HTTP. Verá el uso completo de estos parámetros en los capítulos siguientes mientras explica la estructura del mensaje para solicitudes y respuestas HTTP.

Versión HTTP

HTTP usa un <major>.<minor>esquema de numeración para indicar versiones del protocolo. La versión de un mensaje HTTP se indica mediante un campo Versión HTTP en la primera línea. Aquí está la sintaxis general para especificar el número de versión HTTP:

HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

Ejemplo

HTTP/1.0

or

HTTP/1.1

Identificadores uniformes de recursos (URI)

Los identificadores uniformes de recursos (URI) tienen un formato simple, una cadena que no distingue entre mayúsculas y minúsculas que contiene el nombre, la ubicación, etc. para identificar un recurso, por ejemplo, un sitio web, un servicio web, etc. Una sintaxis general de URI utilizada para HTTP es la siguiente:

URI = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

Aquí si el port está vacío o no se proporciona, el puerto 80 se supone para HTTP y un vacío abs_path es equivalente a un abs_pathde "/". Los personajes distintos a los delreserved y unsafe los conjuntos son equivalentes a su codificación ""% "HEX HEX".

Ejemplo

Los siguientes dos URI son equivalentes:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

Formatos de fecha / hora

Todas las marcas de fecha / hora HTTP DEBEN estar representadas en la hora media de Greenwich (GMT), sin excepción. Las aplicaciones HTTP pueden utilizar cualquiera de las siguientes tres representaciones de marcas de fecha / hora:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Conjuntos de caracteres

Utilice el juego de caracteres para especificar los juegos de caracteres que prefiere el cliente. Se pueden enumerar varios juegos de caracteres separados por comas. Si no se especifica un valor, el valor predeterminado es US-ASCII.

Ejemplo

Los siguientes son conjuntos de caracteres válidos:

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

Codificaciones de contenido

Los valores de ecoding de contenido indican que se ha utilizado un algoritmo de codificación para codificar el contenido antes de pasarlo por la red. Las codificaciones de contenido se utilizan principalmente para permitir que un documento se comprima o se transforme de manera útil sin perder la identidad.

Todos los valores de codificación de contenido no distinguen entre mayúsculas y minúsculas. HTTP / 1.1 utiliza valores de codificación de contenido en los campos de encabezado Accept-Encoding y Content-Encoding que veremos en los capítulos siguientes.

Ejemplo

Los siguientes son esquemas de codificación válidos:

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

Tipos de medios

HTTP utiliza tipos de medios de Internet en el Content-Type y Acceptcampos de encabezado para proporcionar escritura de datos abierta y extensible y negociación de tipos. Todos los valores de tipo de medio se registran con la Autoridad de números asignados de Internet ((IANA). A continuación, se muestra una sintaxis general para especificar el tipo de medio:

media-type     = type "/" subtype *( ";" parameter )

Los nombres de atributo de tipo, subtipo y parámetro no distinguen entre mayúsculas y minúsculas.

Ejemplo

Accept: image/gif

Etiquetas de idioma

HTTP usa etiquetas de idioma dentro del Accept-Language y Content-Languagecampos. Una etiqueta de idioma se compone de 1 o más partes: una etiqueta de idioma principal y una serie posiblemente vacía de subetiquetas:

language-tag  = primary-tag *( "-" subtag )

No se permiten espacios en blanco dentro de la etiqueta y todas las etiquetas no distinguen entre mayúsculas y minúsculas.

Ejemplo

Las etiquetas de ejemplo incluyen:

en, en-US, en-cockney, i-cherokee, x-pig-latin

Donde cualquier etiqueta primaria de dos letras es una abreviatura de idioma ISO-639 y cualquier subetiqueta inicial de dos letras es un código de país ISO-3166.

HTTP se basa en un modelo de arquitectura cliente-servidor y un protocolo de solicitud / respuesta sin estado que opera mediante el intercambio de mensajes a través de una conexión TCP / IP confiable.

Un "cliente" HTTP es un programa (navegador web o cualquier otro cliente) que establece una conexión a un servidor con el propósito de enviar uno o más mensajes de solicitud HTTP. Un "servidor" HTTP es un programa (generalmente un servidor web como Apache Web Server o Internet Information Services IIS, etc.) que acepta conexiones para atender solicitudes HTTP mediante el envío de mensajes de respuesta HTTP.

HTTP utiliza el identificador uniforme de recursos (URI) para identificar un recurso determinado y establecer una conexión. Una vez establecida la conexión,HTTP messagesse pasan en un formato similar al utilizado por el correo de Internet [RFC5322] y las Extensiones de correo de Internet multipropósito (MIME) [RFC2045]. Estos mensajes se componen derequests del cliente al servidor y responses de servidor a cliente que tendrá el siguiente formato:

HTTP-message   = <Request> | <Response> ; HTTP/1.1 messages

La solicitud HTTP y la respuesta HTTP utilizan un formato de mensaje genérico de RFC 822 para transferir los datos requeridos. Este formato de mensaje genérico consta de los siguientes cuatro elementos.


     
      A Start-line
 Zero or more header fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

La siguiente sección explicará cada una de las entidades utilizadas en el mensaje HTTP.

Línea de inicio de mensaje

Una línea de salida tendrá la siguiente sintaxis genérica:

start-line = Request-Line | Status-Line

Analizaremos Request-Line y Status-Line mientras hablamos de los mensajes HTTP Request y HTTP Response respectivamente. Por ahora veamos los ejemplos de la línea de salida en caso de solicitud y respuesta:

GET /hello.htm HTTP/1.1     (This is Request-Line sent by the client)

HTTP/1.1 200 OK             (This is Status-Line sent by the server)

Campos de encabezado

Los campos de HTTP deader proporcionan la información requerida sobre la solicitud o respuesta, o sobre el objeto enviado en el cuerpo del mensaje. Existen los siguientes cuatro tipos de encabezados de mensajes HTTP:

General-header: Estos campos de encabezado tienen aplicabilidad general tanto para mensajes de solicitud como de respuesta.
Request-header: Estos campos de encabezado son aplicables solo para mensajes de solicitud.
Response-header: Estos campos de encabezado son aplicables solo para mensajes de respuesta.
Entity-header: Estos campos de encabezado definen la metainformación sobre el cuerpo de la entidad o, si no hay ningún cuerpo presente

Todos los encabezados mencionados anteriormente siguen el mismo formato genérico y cada uno de los campos de encabezado consta de un nombre seguido de dos puntos (:) y el valor del campo de la siguiente manera:

message-header = field-name ":" [ field-value ]

A continuación se muestran ejemplos de varios campos de encabezado:

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Cuerpo del mensaje

La parte del cuerpo del mensaje es opcional para un mensaje HTTP, pero si está disponible, se usa para llevar el cuerpo de la entidad asociado con la solicitud o respuesta. Si el cuerpo de la entidad está asociado, normalmenteContent-Type y Content-Length Las líneas de encabezado especifican la naturaleza del cuerpo asociado.

El cuerpo de un mensaje es el que contiene datos de solicitud HTTP reales (incluidos los datos del formulario y cargados, etc.) y los datos de respuesta HTTP del servidor (incluidos archivos, imágenes, etc.). A continuación se muestra un contenido simple del cuerpo de un mensaje:

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Un cliente HTTP envía una solicitud HTTP a un servidor en forma de mensaje de solicitud que incluye el siguiente formato:


     
      A Request-line
 Zero or more header (General|Request|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

La siguiente sección explicará cada una de las entidades utilizadas en el mensaje HTTP.

Línea de solicitud de mensaje

Request-Line comienza con un token de método, seguido por Request-URI y la versión del protocolo, y termina con CRLF. Los elementos están separados por caracteres SP de espacio.

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

Analicemos cada una de las partes mencionadas en Request-Line.

Método de solicitud

La solicitud Method indica el método a realizar en el recurso identificado por el dado Request-URI. El método distingue entre mayúsculas y minúsculas y siempre debe mencionarse en mayúsculas. Los siguientes son métodos admitidos en HTTP / 1.1

SN	Método y descripción
1	GET El método GET se usa para recuperar información del servidor dado usando un URI dado. Las solicitudes que utilizan GET solo deben recuperar datos y no deben tener ningún otro efecto en los datos.
2	HEAD Igual que GET, pero solo transfiere la línea de estado y la sección de encabezado.
3	POST Una solicitud POST se utiliza para enviar datos al servidor, por ejemplo, información del cliente, carga de archivos, etc. mediante formularios HTML.
4	PUT Reemplace todas las representaciones actuales del recurso de destino con el contenido cargado.
5	DELETE Elimina todas las representaciones actuales del recurso de destino proporcionadas por URI.
6	CONNECT Establezca un túnel al servidor identificado por un URI determinado.
7	OPTIONS Describa las opciones de comunicación para el recurso de destino.
8	TRACE Realice una prueba de bucle de mensajes a lo largo de la ruta al recurso de destino.

Solicitud-URI

El Request-URI es un identificador uniforme de recursos e identifica el recurso sobre el cual aplicar la solicitud. A continuación, se muestran los formularios más utilizados para especificar un URI:

Request-URI = "*" | absoluteURI | abs_path | authority

SN	Método y descripción
1	El asterisco se utiliza cuando la solicitud HTTP no se aplica a un recurso en particular, sino al servidor mismo, y solo se permite cuando el método utilizado no se aplica necesariamente a un recurso. Por ejemplo: OPTIONS HTTP/1.1**
2	los absoluteURIse utiliza cuando se realiza una solicitud HTTP a un proxy. Se solicita al proxy que reenvíe la solicitud o la atienda desde un caché válido y devuelva la respuesta. Por ejemplo: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3	La forma más común de Request-URI es la que se usa para identificar un recurso en un servidor de origen o puerta de enlace. Por ejemplo, un cliente que desee recuperar el recurso anterior directamente del servidor de origen crearía una conexión TCP al puerto 80 del host "www.w3.org" y enviaría las líneas: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Tenga en cuenta que la ruta absoluta no puede estar vacía; si no hay ninguno presente en el URI original, DEBE indicarse como "/" (la raíz del servidor)

Campos de encabezado de solicitud

Estudiaremos General-header y Entity-header en un capítulo separado cuando aprendamos los campos de encabezado HTTP. Por ahora, veamos qué son los campos de encabezado de solicitud.

Los campos de encabezado de solicitud permiten al cliente pasar información adicional sobre la solicitud y sobre el cliente mismo al servidor. Estos campos actúan como modificadores de solicitud y existen los siguientes campos de encabezado de solicitud importantes disponibles que se pueden usar según los requisitos.

Accept-Charset
Accept-Encoding
Accept-Language
Authorization
Expect
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range
Referer
TE
User-Agent

Puede introducir sus campos personalizados en caso de que vaya a escribir su propio cliente y servidor web personalizados.

Ejemplos de mensajes de solicitud

Ahora pongámoslo todo junto para formar una solicitud HTTP para obtener hello.htm página desde el servidor web que se ejecuta en tutorialspoint.com

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Aquí no estamos enviando ningún dato de solicitud al servidor porque estamos obteniendo una página HTML del plan del servidor. La conexión es un encabezado general que se usa aquí y el resto de los encabezados son encabezados de solicitud. A continuación se muestra un ejemplo más en el que enviamos datos de formulario al servidor utilizando el cuerpo del mensaje de solicitud:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

Aquí se utilizará la URL /cgi-bin/process.cgi dada para procesar los datos pasados y, en consecuencia, se volverá a sintonizar una respuesta. aquícontent-type le dice al servidor que los datos transmitidos son datos simples de formularios web y lengthserá la longitud real de los datos incluidos en el cuerpo del mensaje. El siguiente ejemplo muestra cómo puede pasar XML del plan a su servidor web:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

Después de recibir e interpretar un mensaje de solicitud, un servidor responde con un mensaje de respuesta HTTP:


     
      A Status-line
 Zero or more header (General|Response|Entity) fields followed by CRLF
 An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
 Optionally a message-body

La siguiente sección explicará cada una de las entidades utilizadas en el mensaje HTTP.

Línea de estado del mensaje

La línea de estado que consta de la versión del protocolo seguida de un código de estado numérico y su frase textual asociada. Los elementos están separados por caracteres SP de espacio.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Analicemos cada una de las partes mencionadas en Status-Line.

Versión HTTP

Un servidor que admita HTTP versión 1.1 devolverá la siguiente información de versión:

HTTP-Version = HTTP/1.1

Código de estado

El elemento Status-Code es un número entero de 3 dígitos donde el primer dígito del Status-Code define la clase de respuesta y los dos últimos dígitos no tienen ningún rol de categorización. Hay 5 valores para el primer dígito:

SN	Código y descripción
1	1xx: Informational Esto significa solicitud recibida y proceso continuo.
2	2xx: Success Esto significa que la acción se recibió, comprendió y aceptó correctamente.
3	3xx: Redirection Esto significa que se deben realizar más acciones para completar la solicitud.
4	4xx: Client Error Esto significa que la solicitud contiene una sintaxis incorrecta o no se puede cumplir.
5	5xx: Server Error El servidor no cumplió con una solicitud aparentemente válida

Los códigos de estado HTTP son extensibles y no se requieren aplicaciones HTTP para comprender el significado de todos los códigos de estado registrados. Se proporciona una lista de todos los códigos de estado en un capítulo separado para su referencia.

Campos de encabezado de respuesta

Estudiaremos General-header y Entity-header en un capítulo separado cuando aprendamos los campos de encabezado HTTP. Por ahora, veamos qué son los campos de encabezado de respuesta.

Los campos de encabezado de respuesta permiten al servidor pasar información adicional sobre la respuesta que no se puede colocar en la línea de estado. Estos campos de encabezado brindan información sobre el servidor y sobre el acceso adicional al recurso identificado por el Request-URI.

Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate

Puede introducir sus campos personalizados en caso de que vaya a escribir su propio servidor y cliente web personalizado.

Ejemplos de mensajes de respuesta

Ahora pongámoslo todo junto para formar una respuesta HTTP para una solicitud para obtener hello.htm página desde el servidor web que se ejecuta en tutorialspoint.com

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

A continuación se muestra un ejemplo de mensaje de respuesta HTTP que muestra una condición de error cuando el servidor web no pudo encontrar la página solicitada:

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

A continuación se muestra un ejemplo de mensaje de respuesta HTTP que muestra una condición de error cuando el servidor web encontró una versión HTTP incorrecta en una solicitud HTTP determinada:

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

El conjunto de métodos comunes para HTTP / 1.1 se define a continuación y este conjunto puede ampliarse según los requisitos. Estos nombres de métodos distinguen entre mayúsculas y minúsculas y deben utilizarse en mayúsculas.

SN	Método y descripción
1	GET El método GET se usa para recuperar información del servidor dado usando un URI dado. Las solicitudes que utilizan GET solo deben recuperar datos y no deben tener ningún otro efecto en los datos.
2	HEAD Igual que GET, pero solo transfiere la línea de estado y la sección de encabezado.
3	POST Una solicitud POST se utiliza para enviar datos al servidor, por ejemplo, información del cliente, carga de archivos, etc. mediante formularios HTML.
4	PUT Reemplace todas las representaciones actuales del recurso de destino con el contenido cargado.
5	DELETE Elimina todas las representaciones actuales del recurso de destino proporcionadas por URI.
6	CONNECT Establezca un túnel al servidor identificado por un URI determinado.
7	OPTIONS Describa las opciones de comunicación para el recurso de destino.
8	TRACE Realice una prueba de bucle de mensajes a lo largo de la ruta al recurso de destino.

Método GET

Una solicitud GET recupera datos de un servidor web al especificar parámetros en la parte de la URL de la solicitud. Este es el método principal utilizado para la recuperación de documentos. A continuación se muestra un ejemplo simple que hace uso del método GET para recuperar hello.htm:

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

A continuación, encontrará una respuesta del servidor contra la solicitud GET anterior:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Método HEAD

El método HEAD es funcionalmente como GET, excepto que el servidor responde con una línea de respuesta y encabezados, pero sin cuerpo de entidad. A continuación se muestra un ejemplo simple que hace uso del método HEAD para obtener información de encabezado sobre hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

A continuación, encontrará una respuesta del servidor contra la solicitud GET anterior:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

Puede notar que aquí el servidor no envía ningún dato después del encabezado.

Método POST

El método POST se utiliza cuando desea enviar algunos datos al servidor, por ejemplo, actualización de archivo, datos de formulario, etc. A continuación se muestra un ejemplo simple que utiliza el método POST para enviar datos de formulario al servidor que serán procesados por un process.cgi y finalmente se devolverá una respuesta:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

El script del lado del servidor process.cgi procesa los datos pasados y envía la siguiente respuesta:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

Método PUT

El método PUT se utiliza para solicitar al servidor que almacene el cuerpo de entidad incluido en una ubicación especificada por la URL dada. El siguiente servidor de solicitud de ejemplo para guardar el cuerpo de entidad dado enhello.htm en la raíz del servidor:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

El servidor almacenará el cuerpo de entidad dado en hello.htm archivo y enviará la siguiente respuesta al cliente:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

Método DELETE

El método DELETE se utiliza para solicitar al servidor que elimine el archivo en una ubicación especificada por la URL dada. El siguiente ejemplo solicita al servidor que elimine el archivo dadohello.htm en la raíz del servidor:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

El servidor eliminará el archivo mencionado hello.htm y enviará la siguiente respuesta al cliente:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

Método CONNECT

El cliente utiliza el método CONNECT para establecer una conexión de red a un servidor web a través de HTTP. El siguiente ejemplo solicita una conexión con un servidor web que se ejecuta en el host tutorialspoint.com:

CONNECT www.tutorialspoint.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

La conexión se establece con el servidor y la siguiente respuesta se envía al cliente:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

Método de OPCIONES

El método OPTIONS lo utiliza el cliente para averiguar cuáles son los métodos HTTP y otras opciones admitidas por un servidor web. El cliente puede especificar una URL para el método OPTIONS, o un asterisco (*) para referirse a todo el servidor. El siguiente ejemplo solicita una lista de métodos admitidos por un servidor web que se ejecuta en tutorialspoint.com:

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

El servidor enviará información basada en la configuración actual del servidor, por ejemplo:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

Método TRACE

El método TRACE se usa para enviar el contenido de una solicitud HTTP al solicitante, que se puede usar con fines de depuración en el momento del desarrollo. El siguiente ejemplo muestra el uso del método TRACE:

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

El servidor enviará el siguiente mensaje en respuesta a la solicitud anterior:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.tutorialspoint.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

El elemento Status-Code en una respuesta del servidor es un número entero de 3 dígitos donde el primer dígito del Status-Code define la clase de respuesta y los dos últimos dígitos no tienen ningún rol de categorización. Hay 5 valores para el primer dígito:

SN	Código y descripción
1	1xx: Informational Esto significa solicitud recibida y proceso continuo.
2	2xx: Success Esto significa que la acción se recibió, comprendió y aceptó correctamente.
3	3xx: Redirection Esto significa que se deben realizar más acciones para completar la solicitud.
4	4xx: Client Error Esto significa que la solicitud contiene una sintaxis incorrecta o no se puede cumplir.
5	5xx: Server Error El servidor no cumplió con una solicitud aparentemente válida

Los códigos de estado HTTP son extensibles y no se requieren aplicaciones HTTP para comprender el significado de todos los códigos de estado registrados. A continuación se muestra una lista de todos los códigos de estado.

1xx: Información

Mensaje:	Descripción:
100 Continuar	El servidor solo ha recibido una parte de la solicitud, pero mientras no haya sido rechazada, el cliente debe continuar con la solicitud.
101 protocolos de conmutación	El servidor cambia de protocolo

2xx: exitoso

Mensaje:	Descripción:
200 OK	La solicitud está bien
201 Creado	La solicitud está completa y se crea un nuevo recurso
202 Aceptado	Se acepta la solicitud para su procesamiento, pero el procesamiento no está completo
203 Información no autorizada	La información en el encabezado de la entidad es de una copia local o de terceros, no del servidor original.
204 Sin contenido	Se proporciona un código de estado y un encabezado en la respuesta, pero no hay un cuerpo de entidad en la respuesta.
205 Restablecer contenido	El navegador debe borrar el formulario utilizado para esta transacción para obtener información adicional.
206 Contenido parcial	El servidor está devolviendo datos parciales del tamaño solicitado. Se usa en respuesta a una solicitud que especifica un encabezado de rango . El servidor debe especificar el rango incluido en la respuesta con el encabezado Content-Range .

3xx: redirección

Mensaje:	Descripción:
300 opciones múltiples	Una lista de enlaces. El usuario puede seleccionar un enlace e ir a esa ubicación. Máximo cinco direcciones
301 Movido Permanentemente	La página solicitada se ha movido a una nueva URL.
302 Encontrado	La página solicitada se ha movido temporalmente a una nueva URL.
303 Ver otros	La página solicitada se puede encontrar en una URL diferente
304 no modificado	Este es el código de respuesta a un encabezado If-Modified-Since o If-None-Match , donde la URL no se ha modificado desde la fecha especificada.
305 Usar proxy	Se debe acceder a la URL solicitada a través del proxy mencionado en el encabezado Ubicación .
306 Sin usar	Este código se utilizó en una versión anterior. Ya no se usa, pero el código está reservado
307 redireccionamiento temporal	La página solicitada se ha movido temporalmente a una nueva URL.

4xx: Error del cliente

Mensaje:	Descripción:
400 Petición Incorrecta	El servidor no entendió la solicitud.
401 No autorizado	La página solicitada necesita un nombre de usuario y una contraseña
402 Pago requerido	Aún no puedes usar este código
403 Prohibido	Prohibido el acceso a la página solicitada
404 No encontrado	El servidor no puede encontrar la página solicitada
405 Método no permitido	El método especificado en la solicitud no está permitido.
406 No aceptable	El servidor solo puede generar una respuesta que no es aceptada por el cliente
407 Se requiere autenticación de proxy	Debe autenticarse con un servidor proxy antes de que se pueda atender esta solicitud
408 Solicitar tiempo de espera	La solicitud tardó más de lo que el servidor estaba preparado para esperar
409 Conflicto	La solicitud no se pudo completar debido a un conflicto
410 desaparecido	La página solicitada ya no está disponible
411 Longitud requerida	La "Longitud del contenido" no está definida. El servidor no aceptará la solicitud sin ella
412 Precondición fallida	La condición previa dada en la solicitud evaluada como falsa por el servidor
Solicitud de entidad 413 muy extensa	El servidor no aceptará la solicitud porque la entidad de la solicitud es demasiado grande
414 URL de solicitud demasiado larga	El servidor no aceptará la solicitud porque la URL es demasiado larga. Ocurre cuando conviertes una solicitud de "publicación" en una solicitud de "obtención" con una información de consulta larga
415 Tipo de papel no admitido	El servidor no aceptará la solicitud porque el tipo de medio no es compatible
416 Rango solicitado no satisfactorio	El rango de bytes solicitado no está disponible y está fuera de los límites.
417 Expectativa fallida	Este servidor no pudo cumplir la expectativa dada en un campo de encabezado de solicitud Expect.

5xx: Error del servidor

Mensaje:	Descripción:
Error interno de servidor 500	La solicitud no se completó. El servidor encontró una condición inesperada
501 No implementado	La solicitud no se completó. El servidor no admitía la funcionalidad requerida
502 Puerta de enlace no válida	La solicitud no se completó. El servidor recibió una respuesta no válida del servidor ascendente
503 Servicio no Disponible	La solicitud no se completó. El servidor se está sobrecargando o cayendo temporalmente
504 Tiempo de espera de puerta de enlace	La puerta de enlace ha agotado el tiempo de espera
505 Versión HTTP no compatible	El servidor no admite la versión "protocolo http"

General-header: Estos campos de encabezado tienen aplicabilidad general tanto para mensajes de solicitud como de respuesta.
Client Request-header: Estos campos de encabezado son aplicables solo para mensajes de solicitud.
Server Response-header: Estos campos de encabezado son aplicables solo para mensajes de respuesta.
Entity-header: Estos campos de encabezado definen la metainformación sobre el cuerpo de la entidad o, si no hay ningún cuerpo presente

Encabezados generales

Control de caché

El campo de encabezado general de Cache-Control se utiliza para especificar directivas que DEBEN ser obedecidas por todo el sistema de almacenamiento en caché. A continuación se muestra la sintaxis:

Cache-Control : cache-request-directive|cache-response-directive

Los clientes o servidores HTTP pueden utilizar Cache-controlencabezado general para especificar parámetros para el caché o para solicitar ciertos tipos de documentos del caché. Las directivas de almacenamiento en caché se especifican en una lista separada por comas. Por ejemplo:

Cache-control: no-cache

Existen las siguientes directivas importantes de solicitud de caché que el cliente puede utilizar en su solicitud HTTP:

SN	Descripción y directiva de solicitud de caché
1	no-cache Un caché no debe utilizar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.
2	no-store La caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.
3	max-age = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya antigüedad no supere el tiempo especificado en segundos.
4	max-stale [ = seconds ] Indica que el cliente está dispuesto a aceptar una respuesta que ha excedido su tiempo de vencimiento. Si se dan segundos, no debe caducar más de ese tiempo.
5	min-fresh = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya vigencia de actualización no sea menor que su antigüedad actual más el tiempo especificado en segundos.
6	no-transform No convierta la entidad-cuerpo.
7	only-if-cached No recupere nuevos datos. El caché puede enviar un documento solo si está en el caché y no debe contactar al servidor de origen para ver si existe una copia más nueva.

Existen las siguientes directivas de respuesta de caché importantes que el servidor puede utilizar en su respuesta HTTP:

SN	Descripción y directiva de solicitud de caché
1	public Indica que cualquier caché puede almacenar la respuesta en caché.
2	private Indica que todo o parte del mensaje de respuesta está destinado a un solo usuario y no debe almacenarse en la memoria caché compartida.
3	no-cache Un caché no debe utilizar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.
4	no-store La caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.
5	no-transform No convierta la entidad-cuerpo.
6	must-revalidate El caché debe verificar el estado de los documentos obsoletos antes de usarlo y no se debe usar uno caducado.
7	proxy-revalidate La directiva proxy-revalidate tiene el mismo significado que la directiva must-revalidate, excepto que no se aplica a los cachés de agentes de usuario no compartidos.
8	max-age = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya antigüedad no supere el tiempo especificado en segundos.
9	s-maxage = seconds La edad máxima especificada por esta directiva anula la edad máxima especificada por la directiva max-age o el encabezado Expires. La directiva s-maxage siempre es ignorada por un caché privado.

Conexión

El campo de encabezado general de la conexión permite al remitente especificar las opciones deseadas para esa conexión en particular y no deben ser comunicadas por servidores proxy a través de conexiones adicionales. A continuación se muestra la sintaxis simple de usar el encabezado de conexión:

Connection : "Connection"

HTTP / 1.1 define la opción de conexión "cerrada" para que el remitente indique que la conexión se cerrará una vez completada la respuesta. Por ejemplo:

Connection: Closed

De forma predeterminada, HTTP 1.1 utiliza conexiones persistentes, donde la conexión no se cierra automáticamente después de una transacción. HTTP 1.0, por otro lado, no tiene conexiones persistentes por defecto. Si un cliente 1.0 desea usar conexiones persistentes, usa elkeep-alive parámetro de la siguiente manera:

Connection: keep-alive

Fecha

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Aquí el primer formato es el más preferido.

Pragma

El campo de encabezado general de Pragma se utiliza para incluir directivas específicas de implementación que pueden aplicarse a cualquier destinatario a lo largo de la cadena de solicitud / respuesta. Por ejemplo:

Pragma: no-cache

La única directiva definida en HTTP / 1.0 es la directiva sin caché y se mantiene en HTTP 1.1 para compatibilidad con versiones anteriores. No se definirán nuevas directivas de Pragma en el futuro.

Remolque

El valor del campo general Trailer indica que el conjunto dado de campos de encabezado está presente en el final de un mensaje codificado con codificación de transferencia fragmentada. A continuación se muestra la sintaxis del campo de encabezado del tráiler:

Trailer : field-name

Los campos de encabezado de mensaje enumerados en el campo de encabezado de tráiler no deben incluir los siguientes campos de encabezado:

Transfer-Encoding
Content-Length
Trailer

Codificación de transferencia

El campo de encabezado general Transfer-Encoding indica qué tipo de transformación se ha aplicado al cuerpo del mensaje para transferirlo de forma segura entre el remitente y el destinatario. Esto no es lo mismo que la codificación de contenido porque las codificaciones de transferencia son una propiedad del mensaje, no del cuerpo de la entidad. A continuación se muestra la sintaxis del campo de encabezado Transfer-Encoding:

Transfer-Encoding: chunked

Todos los valores de codificación de transferencia no distinguen entre mayúsculas y minúsculas.

Potenciar

El encabezado general Actualizar permite al cliente especificar qué protocolos de comunicación adicionales admite y le gustaría usar si el servidor lo considera apropiado para cambiar de protocolo. Por ejemplo:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

El campo de encabezado de actualización está destinado a proporcionar un mecanismo simple para la transición de HTTP / 1.1 a algún otro protocolo incompatible

Vía

Las puertas de enlace y los proxies deben utilizar el encabezado general Via para indicar los protocolos y destinatarios intermedios. Por ejemplo, se podría enviar un mensaje de solicitud desde un agente de usuario HTTP / 1.0 a un proxy interno llamado en código "fred", que usa HTTP / 1.1 para reenviar la solicitud a un proxy público en nowhere.com, que completa la solicitud mediante reenviarlo al servidor de origen en www.ics.uci.edu. La solicitud recibida por www.ics.uci.edu tendría entonces el siguiente campo de encabezado Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

El campo de encabezado de actualización está destinado a proporcionar un mecanismo simple para la transición de HTTP / 1.1 a algún otro protocolo incompatible

Advertencia

El encabezado general de Advertencia se utiliza para llevar información adicional sobre el estado o la transformación de un mensaje que podría no reflejarse en el mensaje. Una respuesta puede llevar más de un encabezado de Advertencia.

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Encabezados de solicitud de cliente

Aceptar

El campo Accept request-header se puede usar para especificar ciertos tipos de medios que son aceptables para la respuesta. A continuación se muestra la sintaxis general:

Accept: type/subtype [q=qvalue]

Se pueden enumerar varios tipos de medios separados por comas y el qvalue opcional representa un nivel de calidad aceptable para aceptar tipos en una escala de 0 a 1. A continuación, se muestra un ejemplo:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Esto se interpretaría como text/html y text/x-c son los tipos de medios preferidos, pero si no existen, envíe el text/x-dvi entidad, y si no existe, envíe la text/plain entidad.

Aceptar-Charset

El campo de encabezado de solicitud Accept-Charset se puede utilizar para indicar qué conjuntos de caracteres son aceptables para la respuesta. A continuación se muestra la sintaxis general:

Accept-Charset: character_set [q=qvalue]

Se pueden enumerar varios juegos de caracteres separados por comas y el qvalue opcional representa un nivel de calidad aceptable para los juegos de caracteres no preferidos en una escala de 0 a 1. A continuación se muestra un ejemplo:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

El valor especial "*", si está presente en el Accept-Charset campo, coincide con cada juego de caracteres y si no Accept-Charset encabezado está presente, el valor predeterminado es que cualquier juego de caracteres es aceptable.

Aceptar codificación

El campo Accept-Encoding request-header es similar a Accept, pero restringe las codificaciones de contenido que son aceptables en la respuesta. A continuación se muestra la sintaxis general:

Accept-Encoding: encoding types

Los siguientes son ejemplos:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Aceptar-idioma

El campo de encabezado de solicitud Accept-Language es similar a Accept, pero restringe el conjunto de lenguajes naturales que se prefieren como respuesta a la solicitud. A continuación se muestra la sintaxis general:

Accept-Language: language [q=qvalue]

Se pueden enumerar varios idiomas separados por comas y el qvalue opcional representa un nivel de calidad aceptable para los idiomas no preferidos en una escala de 0 a 1. A continuación, se muestra un ejemplo:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Autorización

El valor del campo de encabezado de solicitud de autorización consta de credenciales que contienen la información de autenticación del agente de usuario para el ámbito del recurso que se solicita. A continuación se muestra la sintaxis general:

Authorization : credentials

La especificación HTTP / 1.0 define el esquema de autorización BÁSICO, donde el parámetro de autorización es la cadena de username:password codificado en base 64. A continuación se muestra un ejemplo:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

El valor se decodifica en es guest:guest123 dónde guest es ID de usuario y guest123 es la contraseña.

Galleta

El valor del campo de encabezado de solicitud de cookie contiene un par de nombre / valor de información almacenada para esa URL. A continuación se muestra la sintaxis general:

Cookie: name=value

Se pueden especificar varias cookies separadas por punto y coma de la siguiente manera:

Cookie: name1=value1;name2=value2;name3=value3

Esperar

El campo Expect request-header se usa para indicar que el cliente requiere comportamientos de servidor particulares. A continuación se muestra la sintaxis general:

Expect : 100-continue | expectation-extension

Si un servidor recibe una solicitud que contiene un campo Expect que incluye una extensión de expectativa que no admite, debe responder con un estado 417 (Expectativa fallida).

Desde

El campo de encabezado de solicitud De contiene una dirección de correo electrónico de Internet para el usuario humano que controla el agente de usuario solicitante. A continuación se muestra un ejemplo sencillo:

From: [email protected]

Este campo de encabezado se puede utilizar para fines de registro y como un medio para identificar la fuente de solicitudes no válidas o no deseadas.

Anfitrión

El campo de encabezado de solicitud de host se utiliza para especificar el host de Internet y el número de puerto del recurso que se solicita. A continuación se muestra la sintaxis general:

Host : "Host" ":" host [ ":" port ] ;

UN hostsin ninguna información de puerto final implica el puerto predeterminado, que es 80. Por ejemplo, una solicitud en el servidor de origen para http://www.w3.org/pub/WWW/ sería:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

El campo de encabezado de solicitud If-Match se usa con un método para hacerlo condicional. Este encabezado solicita al servidor que realice el método solicitado solo si el valor dado en esta etiqueta coincide con las etiquetas de entidad dadas representadas porETag. A continuación se muestra la sintaxis general:

If-Match : entity-tag

Un asterisco (*) coincide con cualquier entidad y la transacción continúa solo si la entidad existe. A continuación se muestran posibles ejemplos:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Si ninguna de las etiquetas de entidad coincide, o si se proporciona "*" y no existe una entidad actual, el servidor no debe realizar el método solicitado y debe devolver una respuesta 412 (Precondición fallida).

Si-modificado-desde

El campo de encabezado de solicitud If-Modified-Since se usa con un método para hacerlo condicional. Si la URL solicitada no se ha modificado desde el momento especificado en este campo, no se devolverá una entidad desde el servidor; en su lugar, se devolverá una respuesta 304 (no modificada) sin ningún cuerpo de mensaje. A continuación se muestra la sintaxis general:

If-Modified-Since : HTTP-date

Un ejemplo del campo es:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Si-no-coincide

El campo de encabezado de solicitud If-None-Match se usa con un método para hacerlo condicional. Este encabezado solicita al servidor que realice el método solicitado solo si uno de los valores dados en esta etiqueta coincide con las etiquetas de entidad dadas representadas porETag. A continuación se muestra la sintaxis general:

If-None-Match : entity-tag

Un asterisco (*) coincide con cualquier entidad y la transacción continúa solo si la entidad no existe. A continuación se muestran posibles ejemplos:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

El campo de encabezado de solicitud If-Range se puede usar con un GET condicional para solicitar solo la parte de la entidad que falta, si no se ha cambiado, y la entidad completa si ha cambiado. A continuación se muestra la sintaxis general:

If-Range : entity-tag | HTTP-date

Se puede usar una etiqueta de entidad o una fecha para identificar la entidad parcial ya recibida. Por ejemplo:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Aquí, si el documento no se ha modificado desde la fecha dada, el servidor devuelve el rango de bytes dado por el encabezado Range; de lo contrario, devuelve todo el documento nuevo.

Si-sin modificar-desde

El campo de encabezado de solicitud If-Unmodified-Since se usa con un método para hacerlo condicional. A continuación se muestra la sintaxis general:

If-Unmodified-Since : HTTP-date

Si el recurso solicitado no se ha modificado desde el momento especificado en este campo, el servidor debe realizar la operación solicitada como si el encabezado If-Unmodified-Since no estuviera presente. Por ejemplo:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Si la solicitud normalmente da como resultado un estado distinto de 2xx o 412, se debe ignorar el encabezado If-Unmodified-Since .

Max-Forwards

El campo de encabezado de solicitud Max-Forwards proporciona un mecanismo con los métodos TRACE y OPTIONS para limitar el número de proxies o puertas de enlace que pueden reenviar la solicitud al siguiente servidor entrante. A continuación se muestra la sintaxis general:

Max-Forwards : n

El valor de Max-Forwards es un número entero decimal que indica el número restante de veces que se puede reenviar este mensaje de solicitud. Esto es útil para depurar con el método TRACE, evitando bucles infinitos. Por ejemplo:

Max-Forwards : 5

El campo de encabezado Max-Forwards puede ignorarse para todos los demás métodos definidos en la especificación HTTP.

Autorización de proxy

El campo de encabezado de solicitud de autorización de proxy permite al cliente identificarse a sí mismo (o su usuario) ante un proxy que requiere autenticación. A continuación se muestra la sintaxis general:

Proxy-Authorization : credentials

El valor del campo Proxy-Authorization consta de credenciales que contienen la información de autenticación del agente de usuario para el proxy y / o dominio del recurso que se solicita.

Rango

El campo de encabezado de solicitud de rango especifica los rangos parciales del contenido solicitado del documento. A continuación se muestra la sintaxis general:

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

El valor de posición del primer byte en una especificación de rango de bytes da el desplazamiento de bytes del primer byte de un rango. El valor de posición del último byte da el desplazamiento de bytes del último byte del rango; es decir, las posiciones de bytes especificadas son inclusivas. Puede especificar una unidad de bytes como bytes Los desplazamientos de bytes comienzan en cero. A continuación se muestran algunos ejemplos sencillos:

- The first 500 bytes 
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

Se pueden enumerar varios rangos, separados por comas. Si falta el primer dígito del rango de bytes separados por comas, se supone que el rango cuenta desde el final del documento. Si falta el segundo dígito, el rango es el byte n hasta el final del documento.

Referer

El campo Referer request-header permite al cliente especificar la dirección (URI) del recurso desde el cual se solicitó la URL. A continuación se muestra la sintaxis general:

Referer : absoluteURI | relativeURI

A continuación se muestra un ejemplo sencillo:

Referer: http://www.tutorialspoint.org/http/index.htm

Si el valor del campo es un URI relativo, debe interpretarse en relación con el URI de solicitud .

TE

El campo de encabezado de solicitud de TE indica qué extensión de codificación de transferencia está dispuesto a aceptar en la respuesta y si está dispuesto a aceptar campos de cola en una codificación de transferencia fragmentada . A continuación se muestra la sintaxis general:

TE   : t-codings

La presencia de la palabra clave "trailers" indica que el cliente está dispuesto a aceptar campos de trailers en una codificación de transferencia fragmentada y se especifica de cualquiera de las formas:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Si el valor de campo TE está vacío o si no hay ningún campo TE presente, se fragmenta la única codificación de transferencia . Un mensaje sin codificación de transferencia siempre es aceptable.

Agente de usuario

El campo de encabezado de solicitud de agente de usuario contiene información sobre el agente de usuario que origina la solicitud. A continuación se muestra la sintaxis general:

User-Agent : product | comment

Ejemplo:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Encabezados de respuesta del servidor

Aceptar rangos

El campo Accept-Ranges response-header permite al servidor indicar su aceptación de solicitudes de rango para un recurso. A continuación se muestra la sintaxis general:

Accept-Ranges  : range-unit | none

Por ejemplo, un servidor que acepta solicitudes de rango de bytes puede enviar

Accept-Ranges: bytes

Los servidores que no acepten ningún tipo de solicitud de rango para un recurso pueden enviar:

Accept-Ranges: none

Esto le avisará al cliente que no intente una solicitud de rango.

Años

El campo de encabezado de respuesta de Edad transmite la estimación del remitente de la cantidad de tiempo desde que se generó la respuesta (o su revalidación) en el servidor de origen. A continuación se muestra la sintaxis general:

Age : delta-seconds

Los valores de edad son números enteros decimales no negativos, que representan el tiempo en segundos. A continuación se muestra un ejemplo sencillo:

Age: 1030

Un servidor HTTP / 1.1 que incluye una caché debe incluir un campo de encabezado Age en cada respuesta generada desde su propia caché.

ETag

El campo de encabezado de respuesta de ETag proporciona el valor actual de la etiqueta de entidad para la variante solicitada. A continuación se muestra la sintaxis general:

ETag :  entity-tag

A continuación se muestran ejemplos sencillos:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Ubicación

El campo de encabezado de respuesta de ubicación se utiliza para redirigir al destinatario a una ubicación que no sea el URI de solicitud para completarlo. A continuación se muestra la sintaxis general:

Location : absoluteURI

A continuación se muestra un ejemplo sencillo:

Location: http://www.tutorialspoint.org/http/index.htm

El campo de encabezado Content-Location difiere de Location en que Content-Location identifica la ubicación original de la entidad incluida en la solicitud.

Proxy-Authenticate

El campo de encabezado de respuesta Proxy-Authenticate debe incluirse como parte de una respuesta 407 (Se requiere autenticación de proxy). A continuación se muestra la sintaxis general:

Proxy-Authenticate  : challenge

Reintentar-Después

El campo Reintentar-Después de respuesta-encabezado se puede usar con una respuesta 503 (Servicio no disponible) para indicar cuánto tiempo se espera que el servicio no esté disponible para el cliente solicitante. A continuación se muestra la sintaxis general:

Retry-After : HTTP-date | delta-seconds

A continuación se muestran dos ejemplos sencillos:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

En el último ejemplo, el retraso es de 2 minutos.

Servidor

El campo de encabezado de respuesta del servidor contiene información sobre el software utilizado por el servidor de origen para manejar la solicitud. A continuación se muestra la sintaxis general:

Server : product | comment

A continuación se muestra un ejemplo sencillo:

Server: Apache/2.2.14 (Win32)

Si la respuesta se reenvía a través de un proxy, la aplicación del proxy no debe modificar el encabezado de respuesta del servidor.

Set-Cookie

El campo de encabezado de respuesta Set-Cookie contiene un par de información de nombre / valor para retener para esta URL. A continuación se muestra la sintaxis general:

Set-Cookie: NAME=VALUE; OPTIONS

El encabezado de respuesta Set-Cookie comprende el token Set-Cookie :, seguido de una lista separada por comas de una o más cookies. Aquí hay valores posibles que puede especificar como opciones:

SN	Opciones y descripción
1	Comment=comment Esta opción se puede utilizar para especificar cualquier comentario asociado con la cookie.
2	Domain=domain El atributo de dominio especifica el dominio para el que la cookie es válida.
3	Expires=Date-time La fecha de caducidad de la cookie. Si está en blanco, la cookie caducará cuando el visitante salga del navegador.
4	Path=path El atributo Ruta especifica el subconjunto de URL a las que se aplica esta cookie.
5	Secure Esto le indica al agente de usuario que devuelva la cookie solo bajo una conexión segura.

A continuación, se muestra un ejemplo de un encabezado de cookie simple generado por el servidor:

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Variar

El campo Vary response-header especifica que la entidad tiene múltiples fuentes y, por lo tanto, puede variar según la lista especificada de encabezados de solicitud. A continuación se muestra la sintaxis general:

Vary : field-name

Puede especificar varios encabezados separados por comas y un valor de asterisco "*" indica que los parámetros no especificados no se limitan a los encabezados de solicitud. A continuación se muestra un ejemplo sencillo:

Vary: Accept-Language, Accept-Encoding

Aquí los nombres de campo no distinguen entre mayúsculas y minúsculas.

Autenticación WWW

El campo de encabezado de respuesta WWW-Authenticate debe incluirse en los mensajes de respuesta 401 (no autorizados). El valor del campo consta de al menos un desafío que indica los esquemas de autenticación y los parámetros aplicables a la Solicitud-URI. A continuación se muestra la sintaxis general:

WWW-Authenticate : challenge

WWW: valor del campo de autenticación, ya que puede contener más de un desafío, o si se proporciona más de un campo de encabezado WWW-Authenticate, el contenido de un desafío en sí puede contener una lista de parámetros de autenticación separados por comas. A continuación se muestra un ejemplo sencillo:

WWW-Authenticate: BASIC realm="Admin"

Encabezados de entidad

Permitir

El campo Permitir encabezado de entidad enumera el conjunto de métodos admitidos por el recurso identificado por el URI de solicitud. A continuación se muestra la sintaxis general:

Allow : Method

Puede especificar varios métodos separados por comas. A continuación se muestra un ejemplo sencillo:

Allow: GET, HEAD, PUT

Este campo no puede evitar que un cliente pruebe otros métodos.

Codificación de contenido

El campo de encabezado de entidad Content-Encoding se utiliza como un modificador del tipo de medio. A continuación se muestra la sintaxis general:

Content-Encoding : content-coding

La codificación de contenido es una característica de la entidad identificada por el Request-URI. A continuación se muestra un ejemplo sencillo:

Content-Encoding: gzip

Si la codificación de contenido de una entidad en un mensaje de solicitud no es aceptable para el servidor de origen, el servidor debe responder con un código de estado 415 (Tipo de medio no admitido).

Contenido-Idioma

El campo de encabezado de la entidad Content-Language describe el (los) lenguaje (s) natural (s) de la audiencia prevista para la entidad adjunta. A continuación se muestra la sintaxis general:

Content-Language : language-tag

Es posible que se enumeren varios idiomas para el contenido destinado a múltiples audiencias. A continuación se muestra un ejemplo sencillo:

Content-Language: mi, en

El propósito principal de Content-Language es permitir a un usuario identificar y diferenciar entidades de acuerdo con el idioma preferido del usuario.

Largancia de contenido

El campo de encabezado de entidad Content-Length indica el tamaño del cuerpo de entidad, en número decimal de OCTET, enviado al destinatario o, en el caso del método HEAD, el tamaño del cuerpo de entidad que se habría enviado si la solicitud ha sido un GET. A continuación se muestra la sintaxis general:

Content-Length : DIGITS

A continuación se muestra un ejemplo sencillo:

Content-Length: 3495

Cualquier longitud de contenido mayor o igual a cero es un valor válido.

Ubicación del contenido

El campo de encabezado de entidad de ubicación de contenido se puede usar para proporcionar la ubicación de recursos para la entidad incluida en el mensaje cuando esa entidad es accesible desde una ubicación separada del URI del recurso solicitado. A continuación se muestra la sintaxis general:

Content-Location:  absoluteURI | relativeURI

A continuación se muestra un ejemplo sencillo:

Content-Location: http://www.tutorialspoint.org/http/index.htm

El valor de Content-Location también define el URI base de la entidad.

Contenido-MD5

El campo de encabezado de entidad Content-MD5 se puede utilizar para proporcionar un resumen MD5 de la entidad, para verificar la integridad del mensaje al recibirlo. A continuación se muestra la sintaxis general:

Content-MD5  : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

A continuación se muestra un ejemplo sencillo:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

El resumen MD5 se calcula en función del contenido del cuerpo de la entidad, incluida cualquier codificación de contenido que se haya aplicado, pero sin incluir la codificación de transferencia aplicada al cuerpo del mensaje.

Rango de contenido

El campo de encabezado de entidad de rango de contenido se envía con un cuerpo de entidad parcial para especificar en qué parte del cuerpo de entidad completo debe aplicarse el cuerpo parcial. A continuación se muestra la sintaxis general:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

Ejemplos de valores de byte-content-range-spec, asumiendo que la entidad contiene un total de 1234 bytes:

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

Cuando un mensaje HTTP incluye el contenido de un solo rango, este contenido se transmite con un encabezado Content-Range y un encabezado Content-Length que muestra el número de bytes realmente transferidos. Por ejemplo,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Tipo de contenido

El campo de encabezado de entidad de tipo de contenido indica el tipo de medio del cuerpo de entidad enviado al destinatario o, en el caso del método HEAD, el tipo de medio que se habría enviado si la solicitud hubiera sido un GET. A continuación se muestra la sintaxis general:

Content-Type : media-type

A continuación se muestra un ejemplo:

Content-Type: text/html; charset=ISO-8859-4

Expira

El campo de encabezado de entidad Expires proporciona la fecha / hora después de la cual la respuesta se considera obsoleta. A continuación se muestra la sintaxis general:

Expires : HTTP-date

A continuación se muestra un ejemplo:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Última modificación

El campo de encabezado de entidad Última modificación indica la fecha y hora en que el servidor de origen cree que la variante se modificó por última vez. A continuación se muestra la sintaxis general:

Last-Modified: HTTP-date

A continuación se muestra un ejemplo:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

HTTP se utiliza normalmente para sistemas de información distribuidos, donde el rendimiento se puede mejorar mediante el uso de cachés de respuesta. El protocolo HTTP / 1.1 incluye una serie de elementos destinados a que el almacenamiento en caché funcione.

El objetivo del almacenamiento en caché en HTTP / 1.1 es eliminar la necesidad de enviar solicitudes en muchos casos y eliminar la necesidad de enviar respuestas completas en muchos otros casos.

Los mecanismos básicos de caché en HTTP / 1.1 son directivas implícitas para cachés donde el servidor especifica los tiempos de vencimiento y los validadores. Usamos elCache-Control encabezado para este propósito.

los Cache-ControlEl encabezado permite que un cliente o servidor transmita una variedad de directivas en solicitudes o respuestas. Estas directivas normalmente anulan los algoritmos de almacenamiento en caché predeterminados. Las directivas de almacenamiento en caché se especifican en una lista separada por comas. Por ejemplo:

Cache-control: no-cache

Existen las siguientes directivas importantes de solicitud de caché que el cliente puede utilizar en su solicitud HTTP:

SN	Descripción y directiva de solicitud de caché
1	no-cache Un caché no debe utilizar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.
2	no-store La caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.
3	max-age = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya antigüedad no supere el tiempo especificado en segundos.
4	max-stale [ = seconds ] Indica que el cliente está dispuesto a aceptar una respuesta que ha excedido su tiempo de vencimiento. Si se dan segundos, no debe caducar más de ese tiempo.
5	min-fresh = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya vigencia de actualización no sea menor que su antigüedad actual más el tiempo especificado en segundos.
6	no-transform No convierta la entidad-cuerpo.
7	only-if-cached No recupere nuevos datos. El caché puede enviar un documento solo si está en el caché y no debe contactar al servidor de origen para ver si existe una copia más nueva.

Existen las siguientes directivas de respuesta de caché importantes que el servidor puede utilizar en su respuesta HTTP:

SN	Directiva y descripción de respuesta de caché
1	public Indica que cualquier caché puede almacenar la respuesta en caché.
2	private Indica que todo o parte del mensaje de respuesta está destinado a un solo usuario y no debe almacenarse en la memoria caché compartida.
3	no-cache Un caché no debe utilizar la respuesta para satisfacer una solicitud posterior sin una revalidación exitosa con el servidor de origen.
4	no-store La caché no debe almacenar nada sobre la solicitud del cliente o la respuesta del servidor.
5	no-transform No convierta la entidad-cuerpo.
6	must-revalidate El caché debe verificar el estado de los documentos obsoletos antes de usarlo y no se debe usar uno caducado.
7	proxy-revalidate La directiva proxy-revalidate tiene el mismo significado que la directiva must-revalidate, excepto que no se aplica a los cachés de agentes de usuario no compartidos.
8	max-age = seconds Indica que el cliente está dispuesto a aceptar una respuesta cuya antigüedad no supere el tiempo especificado en segundos.
9	s-maxage = seconds La edad máxima especificada por esta directiva anula la edad máxima especificada por la directiva max-age o el encabezado Expires. La directiva s-maxage siempre es ignorada por un caché privado.

Las URL HTTP solo se pueden enviar a través de Internet utilizando el conjunto de caracteres ASCII , que a menudo contiene caracteres fuera del conjunto ASCII. Por lo tanto, estos caracteres inseguros deben reemplazarse con un% seguido de dos dígitos hexadecimales.

La siguiente tabla muestra el símbolo ASCII del carácter y su símbolo igual y finalmente su reemplazo que se puede usar en la URL antes de pasarlo al servidor:

ASCII	Símbolo	Reemplazo
<32		Codifique con% xx donde xx es la representación hexadecimal del carácter.
32	espacio	+ o% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	PS	% 24
37	%	% 25
38	Y	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	<	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
sesenta y cinco	UN	UN
66	segundo	segundo
67	C	C
68	re	re
69	mi	mi
70	F	F
71	GRAMO	GRAMO
72	H	H
73	yo	yo
74	J	J
75	K	K
76	L	L
77	METRO	METRO
78	norte	norte
79	O	O
80	PAGS	PAGS
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	'	% 60
97	un	un
98	segundo	segundo
99	C	C
100	re	re
101	mi	mi
102	F	F
103	gramo	gramo
104	h	h
105	yo	yo
106	j	j
107	k	k
108	l	l
109	metro	metro
110	norte	norte
111	o	o
112	pags	pags
113	q	q
114	r	r
115	s	s
116	t	t
117	tu	tu
118	v	v
119	w	w
120	X	X
121	y	y
122	z	z
123	{	% 7B
124	\|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		Codifique con% xx donde xx es la representación hexadecimal del carácter

HTTP se utiliza para una comunicación a través de Internet, por lo que los desarrolladores de aplicaciones, los proveedores de información y los usuarios deben conocer las limitaciones de seguridad de HTTP / 1.1. Esta discusión no incluye soluciones definitivas a los problemas mencionados aquí, pero sí hace algunas sugerencias para reducir los riesgos de seguridad.

Fuga de información personal

Los clientes HTTP suelen tener acceso a una gran cantidad de información personal, como el nombre del usuario, la ubicación, la dirección de correo, las contraseñas, las claves de cifrado, etc. Por lo tanto, debe tener mucho cuidado para evitar la filtración involuntaria de esta información a otras fuentes a través del protocolo HTTP.

Toda la información confidencial debe almacenarse en el lado del servidor en forma cifrada.
Revelar la versión de software específica del servidor podría permitir que la máquina del servidor se vuelva más vulnerable a ataques contra software que se sabe que contiene agujeros de seguridad.
Los proxies que sirven como portal a través de un firewall de red deben tomar precauciones especiales con respecto a la transferencia de información de encabezado que identifica a los hosts detrás del firewall.
La información enviada en el campo De puede entrar en conflicto con los intereses de privacidad del usuario o la política de seguridad de su sitio y, por lo tanto, no debe transmitirse sin que el usuario pueda deshabilitar, habilitar y modificar el contenido del campo.
Los clientes no deben incluir un campo de encabezado Referer en una solicitud HTTP (no segura) si la página de referencia se transfirió con un protocolo seguro.
Los autores de los servicios que utilizan el protocolo HTTP no deben utilizar formularios basados en GET para el envío de datos sensibles, ya que esto provocará que estos datos se codifiquen en el Request-URI.

Ataque basado en nombres de archivos y rutas

El documento debe restringirse a los documentos devueltos por solicitudes HTTP para que sean solo aquellos que fueron previstos por los administradores del servidor.

Por ejemplo, UNIX, Microsoft Windows y otros sistemas operativos utilizan ..como un componente de ruta para indicar un nivel de directorio por encima del actual. En tal sistema, un servidor HTTP DEBE rechazar cualquier construcción de este tipo en el Request-URI si de otra manera permitiría el acceso a un recurso fuera de los destinados a ser accesibles a través del servidor HTTP.

Suplantación de DNS

Los clientes que usan HTTP dependen en gran medida del Servicio de nombres de dominio y, por lo tanto, generalmente son propensos a ataques de seguridad basados en la asociación errónea deliberada de direcciones IP y nombres DNS. Por lo tanto, los clientes deben tener cuidado al asumir la validez continua de una asociación de nombre DNS / número IP.

Si los clientes HTTP almacenan en caché los resultados de las búsquedas de nombres de host para lograr una mejora del rendimiento, deben observar la información TTL proporcionada por DNS. Si los clientes HTTP no observan esta regla, podrían ser falsificados cuando cambie la dirección IP de un servidor al que se haya accedido anteriormente.

Encabezados de ubicación y suplantación de identidad

Si un solo servidor admite varias organizaciones que no confían entre sí, DEBE verificar los valores de los encabezados Ubicación y Contenido-Ubicación en las respuestas que se generan bajo el control de dichas organizaciones para asegurarse de que no intenten invalidar recursos sobre los cuales no tienen autoridad.

Credenciales de autenticación

Los agentes de usuario y los clientes HTTP existentes suelen conservar la información de autenticación de forma indefinida. HTTP / 1.1. no proporciona un método para que un servidor dirija a los clientes a descartar estas credenciales almacenadas en caché, lo cual es un gran riesgo de seguridad.

Hay una serie de soluciones para algunas partes de este problema, por lo que se recomienda utilizar protección con contraseña en los protectores de pantalla, tiempos de espera inactivos y otros métodos que mitiguen los problemas de seguridad inherentes a este problema.

Proxies y caché

Los proxies HTTP son hombres en el medio y representan una oportunidad para los ataques de intermediarios. Los apoderados tienen acceso a información relacionada con la seguridad, información personal sobre usuarios individuales y organizaciones, e información de propiedad que pertenece a usuarios y proveedores de contenido.

Los operadores de proxy deben proteger los sistemas en los que se ejecutan los proxies, ya que protegerían cualquier sistema que contenga o transporte información confidencial.

Los proxies de caché proporcionan vulnerabilidades potenciales adicionales, ya que el contenido de la caché representa un objetivo atractivo para la explotación malintencionada. Por lo tanto, el contenido de la caché debe protegerse como información confidencial.

Ejemplo 1

Solicitud HTTP para recuperar hello.htmpágina desde el servidor web que se ejecuta en tutorialspoint.com

Solicitud de cliente

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Respuesta del servidor

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Ejemplo 2

Solicitud HTTP para recuperar t.htmlpágina que no existe en el servidor web que se ejecuta en tutorialspoint.com

Solicitud de cliente

GET /t.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Respuesta del servidor

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Ejemplo 3

Solicitud HTTP para recuperar hello.htmpágina desde el servidor web que se ejecuta en tutorialspoint.com , pero la solicitud va con una versión HTTP incorrecta:

Solicitud de cliente

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Respuesta del servidor

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Ejemplo 4

Solicitud HTTP para publicar datos de formulario en process.cgiPágina CGI en un servidor web que se ejecuta en tutorialspoint.com . El servidor devuelve el nombre pasado después de configurarlos como cookies:

Solicitud de cliente

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

Respuesta del servidor

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=tutorialspoint.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>