HTTP - Guia rápido

O Hypertext Transfer Protocol (HTTP) é um protocolo de nível de aplicativo para sistemas de informação hipermídia distribuídos e colaborativos. Esta é a base para a comunicação de dados para a World Wide Web (ou seja, internet) desde 1990. HTTP é um protocolo genérico e sem estado que pode ser usado para outros fins, usando a extensão de seus métodos de solicitação, códigos de erro e cabeçalhos.

Basicamente, o HTTP é um protocolo de comunicação baseado em TCP / IP, que é usado para entregar dados (arquivos HTML, arquivos de imagem, resultados de consultas, etc.) na World Wide Web. A porta padrão é TCP 80, mas outras portas podem ser usadas. Ele fornece uma maneira padronizada para os computadores se comunicarem entre si. A especificação HTTP especifica como os dados das solicitações dos clientes serão construídos e enviados ao servidor e como os servidores respondem a essas solicitações.

Recursos básicos

Existem três recursos básicos a seguir que tornam o HTTP um protocolo simples, mas poderoso:

HTTP is connectionless:O cliente HTTP, ou seja, navegador inicia uma solicitação HTTP e depois que uma solicitação é feita, o cliente se desconecta do servidor e espera por uma resposta. O servidor processa a solicitação e restabelece a conexão com o cliente para enviar a resposta de volta.
HTTP is media independent:Isso significa que qualquer tipo de dado pode ser enviado por HTTP, desde que o cliente e o servidor saibam como lidar com o conteúdo dos dados. Isso é necessário para o cliente e também para o servidor especificar o tipo de conteúdo usando o tipo MIME apropriado.
HTTP is stateless:Conforme mencionado acima, o HTTP não tem conexão e isso é um resultado direto de que o HTTP é um protocolo sem estado. O servidor e o cliente estão cientes um do outro apenas durante uma solicitação atual. Depois, os dois se esquecem um do outro. Devido a essa natureza do protocolo, nem o cliente nem o navegador podem reter informações entre diferentes solicitações nas páginas da web.

HTTP / 1.0 usa uma nova conexão para cada troca de solicitação / resposta, enquanto uma conexão HTTP / 1.1 pode ser usada para uma ou mais trocas de solicitação / resposta.

Arquitetura Básica

O diagrama a seguir mostra uma arquitetura muito básica de um aplicativo da web e descreve onde fica o HTTP:

O protocolo HTTP é um protocolo de solicitação / resposta baseado em arquitetura baseada em cliente / servidor onde o navegador da web, robôs e motores de busca, etc. agem como clientes HTTP e o servidor Web atua como servidor.

Cliente

O cliente HTTP envia uma solicitação ao servidor na forma de um método de solicitação, URI e versão do protocolo, seguido por uma mensagem do tipo MIME contendo modificadores de solicitação, informações do cliente e possível conteúdo do corpo por meio de uma conexão TCP / IP.

Servidor

O servidor HTTP responde com uma linha de status, incluindo a versão do protocolo da mensagem e um código de sucesso ou erro, seguido por uma mensagem semelhante a MIME contendo informações do servidor, metainformação da entidade e possível conteúdo do corpo da entidade.

Este capítulo listará alguns dos parâmetros importantes do protocolo HTTP e sua sintaxe de uma forma que são usados na comunicação. Por exemplo, formato para data, formato de URL etc. Isso o ajudará a construir suas mensagens de solicitação e resposta enquanto escreve programas de cliente ou servidor HTTP. Você verá o uso completo desses parâmetros nos capítulos subsequentes enquanto explica a estrutura da mensagem para solicitações e respostas HTTP.

Versão HTTP

HTTP usa um <major>.<minor>esquema de numeração para indicar versões do protocolo. A versão de uma mensagem HTTP é indicada por um campo HTTP-Version na primeira linha. Esta é a sintaxe geral para especificar o número da versão HTTP:

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

Exemplo

HTTP/1.0

or

HTTP/1.1

Identificadores Uniformes de Recursos (URI)

Uniform Resource Identifiers (URI) é simplesmente formatado, string insensível a maiúsculas e minúsculas contendo nome, localização, etc., para identificar um recurso, por exemplo, um site, um serviço da web etc. Uma sintaxe geral de URI usada para HTTP é a seguinte:

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

Aqui se o port está vazio ou não fornecido, a porta 80 é assumida para HTTP e um vazio abs_path é equivalente a um abs_pathdo "/". Os outros personagens além dosreserved e unsafe conjuntos são equivalentes à sua codificação ""% "HEX HEX".

Exemplo

Os dois URIs a seguir são equivalentes:

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

Formatos de data / hora

Todos os carimbos de data / hora HTTP DEVEM ser representados no horário de Greenwich (GMT), sem exceção. Os aplicativos HTTP podem usar qualquer uma das três representações de carimbos de data / hora a seguir:

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

Você usa o conjunto de caracteres para especificar os conjuntos de caracteres que o cliente prefere. Vários conjuntos de caracteres podem ser listados separados por vírgulas. Se um valor não for especificado, o padrão é US-ASCII.

Exemplo

A seguir estão os conjuntos de caracteres válidos:

US-ASCII

or

ISO-8859-1

or 

ISO-8859-7

Codificações de conteúdo

Os valores de codificação de conteúdo indicam que um algoritmo de codificação foi usado para codificar o conteúdo antes de transmiti-lo pela rede. Codificações de conteúdo são usadas principalmente para permitir que um documento seja compactado ou de outra forma transformado de forma útil sem perder a identidade.

Todos os valores de codificação de conteúdo não diferenciam maiúsculas de minúsculas. HTTP / 1.1 usa valores de codificação de conteúdo nos campos de cabeçalho Accept-Encoding e Content-Encoding, que veremos nos capítulos subsequentes.

Exemplo

A seguir estão os esquemas de codificação válidos:

Accept-encoding: gzip

or

Accept-encoding: compress

or 

Accept-encoding: deflate

Tipos de mídia

HTTP usa tipos de mídia da Internet no Content-Type e Acceptcampos de cabeçalho para fornecer digitação de dados aberta e extensível e negociação de tipo. Todos os valores de tipo de mídia são registrados na Internet Assigned Number Authority ((IANA). A seguir está uma sintaxe geral para especificar o tipo de mídia:

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

Os nomes dos atributos de tipo, subtipo e parâmetro não diferenciam maiúsculas de minúsculas.

Exemplo

Accept: image/gif

Tags de linguagem

HTTP usa tags de idioma dentro do Accept-Language e Content-LanguageCampos. Uma tag de idioma é composta por 1 ou mais partes: Uma tag de idioma principal e uma série possivelmente vazia de subtags:

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

O espaço em branco não é permitido na tag e todas as tags não diferenciam maiúsculas de minúsculas.

Exemplo

Tags de exemplo incluem:

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

Onde qualquer etiqueta primária de duas letras é uma abreviatura de idioma ISO-639 e qualquer subetiqueta inicial de duas letras é um código de país ISO-3166.

HTTP é baseado no modelo de arquitetura cliente-servidor e um protocolo de solicitação / resposta sem estado que opera trocando mensagens por meio de uma conexão TCP / IP confiável.

Um "cliente" HTTP é um programa (navegador da Web ou qualquer outro cliente) que estabelece uma conexão com um servidor com o objetivo de enviar uma ou mais mensagens de solicitação HTTP. Um "servidor" HTTP é um programa (geralmente um servidor web como o Apache Web Server ou Internet Information Services IIS etc.) que aceita conexões para atender a solicitações HTTP enviando mensagens de resposta HTTP.

O HTTP usa o Uniform Resource Identifier (URI) para identificar um determinado recurso e estabelecer uma conexão. Assim que a conexão for estabelecida,HTTP messagessão transmitidos em um formato semelhante ao usado pelo correio da Internet [RFC5322] e as Extensões de correio da Internet multiuso (MIME) [RFC2045]. Essas mensagens são compostas porrequests do cliente para o servidor e responses do servidor para o cliente, que terá o seguinte formato:

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

A solicitação e a resposta HTTP usam um formato de mensagem genérico de RFC 822 para transferir os dados necessários. Este formato de mensagem genérico consiste nos quatro itens a seguir.


     
      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

A seção a seguir explicará cada uma das entidades usadas na mensagem HTTP.

Message Start-Line

Uma linha de partida terá a seguinte sintaxe genérica:

start-line = Request-Line | Status-Line

Discutiremos a linha de solicitação e a linha de status enquanto discutimos as mensagens de solicitação e resposta HTTP, respectivamente. Por enquanto, vamos ver os exemplos de linha de partida em caso de solicitação e resposta:

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 cabeçalho

Os campos HTTP deader fornecem informações necessárias sobre a solicitação ou resposta, ou sobre o objeto enviado no corpo da mensagem. Existem quatro tipos de cabeçalhos de mensagens HTTP a seguir:

General-header: Esses campos de cabeçalho têm aplicabilidade geral para mensagens de solicitação e resposta.
Request-header: Esses campos de cabeçalho são aplicáveis apenas para mensagens de solicitação.
Response-header: Esses campos de cabeçalho são aplicáveis apenas para mensagens de resposta.
Entity-header: Esses campos de cabeçalho definem metainformações sobre o corpo da entidade ou, se nenhum corpo estiver presente

Todos os cabeçalhos mencionados acima seguem o mesmo formato genérico e cada um dos campos de cabeçalho consiste em um nome seguido por dois pontos (:) e o valor do campo da seguinte forma:

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

A seguir estão os exemplos de vários campos de cabeçalho:

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

Corpo da mensagem

A parte do corpo da mensagem é opcional para uma mensagem HTTP, mas se estiver disponível, é usada para transportar o corpo da entidade associado à solicitação ou resposta. Se o corpo da entidade estiver associado, geralmenteContent-Type e Content-Length as linhas dos cabeçalhos especificam a natureza do corpo associado.

Um corpo de mensagem é aquele que carrega dados reais de solicitação HTTP (incluindo dados de formulário e upload, etc.) e dados de resposta HTTP do servidor (incluindo arquivos, imagens, etc.). A seguir está um conteúdo simples de um corpo de mensagem:

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

Um cliente HTTP envia uma solicitação HTTP a um servidor na forma de uma mensagem de solicitação que inclui o seguinte 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

A seção a seguir explicará cada uma das entidades usadas na mensagem HTTP.

Linha de Solicitação de Mensagem

O Request-Line começa com um token de método, seguido pelo Request-URI e a versão do protocolo, e termina com CRLF. Os elementos são separados por caracteres de espaço SP.

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

Vamos discutir cada uma das partes mencionadas em Request-Line.

Método de Solicitação

O pedido Method indica o método a ser executado no recurso identificado pelo dado Request-URI. O método diferencia maiúsculas de minúsculas e deve ser sempre mencionado em maiúsculas. A seguir estão os métodos suportados em HTTP / 1.1

SN	Método e Descrição
1	GET O método GET é usado para recuperar informações de um determinado servidor usando um determinado URI. As solicitações que usam GET devem apenas recuperar dados e não devem ter nenhum outro efeito sobre os dados.
2	HEAD O mesmo que GET, mas apenas transfere a linha de status e a seção do cabeçalho.
3	POST Uma solicitação POST é usada para enviar dados ao servidor, por exemplo, informações do cliente, upload de arquivo, etc., usando formulários HTML.
4	PUT Substitua todas as representações atuais do recurso de destino com o conteúdo carregado.
5	DELETE Remova todas as representações atuais do recurso de destino fornecido pelo URI.
6	CONNECT Estabeleça um túnel para o servidor identificado por um determinado URI.
7	OPTIONS Descreva as opções de comunicação para o recurso de destino.
8	TRACE Execute um teste de loopback de mensagem ao longo do caminho para o recurso de destino.

Request-URI

O Request-URI é um Uniform Resource Identifier e identifica o recurso sobre o qual aplicar a solicitação. A seguir estão os formulários mais comumente usados para especificar um URI:

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

SN	Método e Descrição
1	O asterisco é usado quando a solicitação HTTP não se aplica a um recurso específico, mas ao próprio servidor, e só é permitido quando o método usado não se aplica necessariamente a um recurso. Por exemplo: OPTIONS HTTP/1.1**
2	o absoluteURIé usado quando a solicitação HTTP está sendo feita para um proxy. O proxy é solicitado para encaminhar a solicitação ou serviço de um cache válido e retornar a resposta. Por exemplo: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
3	A forma mais comum de Request-URI é aquela usada para identificar um recurso em um servidor ou gateway de origem. Por exemplo, um cliente que deseja recuperar o recurso acima diretamente do servidor de origem criaria uma conexão TCP para a porta 80 do host "www.w3.org" e enviaria as linhas: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Observe que o caminho absoluto não pode estar vazio; se nenhum estiver presente no URI original, DEVE ser fornecido como "/" (a raiz do servidor)

Solicitar campos de cabeçalho

Estudaremos o cabeçalho geral e o cabeçalho de entidade em um capítulo separado, quando aprenderemos os campos de cabeçalho HTTP. Por enquanto, vamos verificar quais são os campos de cabeçalho de solicitação.

Os campos do cabeçalho da solicitação permitem que o cliente passe informações adicionais sobre a solicitação e sobre o próprio cliente para o servidor. Esses campos agem como modificadores de solicitação e existem os seguintes campos importantes de cabeçalho de solicitação disponíveis que podem ser usados com base no requisito.

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

Você pode introduzir seus campos personalizados no caso de escrever seu próprio cliente e servidor web personalizados.

Exemplos de mensagens de solicitação

Agora vamos juntar tudo para formar uma solicitação HTTP para buscar hello.htm página do servidor da web em execução em 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

Aqui, não estamos enviando nenhum dado de solicitação ao servidor porque estamos obtendo uma página HTML do plano do servidor. Conexão é um cabeçalho geral usado aqui e o restante dos cabeçalhos são cabeçalhos de solicitação. A seguir está mais um exemplo em que enviamos dados do formulário para o servidor usando o corpo da mensagem de solicitação:

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

Aqui, o URL /cgi-bin/process.cgi fornecido será usado para processar os dados transmitidos e, portanto, uma resposta será ajustada novamente. Aquicontent-type diz ao servidor que os dados transmitidos são dados simples de formulário da web e lengthserá o comprimento real dos dados colocados no corpo da mensagem. O exemplo a seguir mostra como você pode passar o XML do plano para o seu servidor da 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>

Depois de receber e interpretar uma mensagem de solicitação, um servidor responde com uma mensagem de resposta 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

A seção a seguir explicará cada uma das entidades usadas na mensagem HTTP.

Linha de status da mensagem

A linha de status consiste na versão do protocolo seguida por um código de status numérico e sua frase textual associada. Os elementos são separados por caracteres de espaço SP.

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

Vamos discutir cada uma das partes mencionadas em Status-Line.

Versão HTTP

Um servidor compatível com HTTP versão 1.1 retornará as seguintes informações de versão:

HTTP-Version = HTTP/1.1

Código de Status

O elemento Status-Code é um número inteiro de 3 dígitos onde o primeiro dígito do Status-Code define a classe de resposta e os dois últimos dígitos não têm qualquer função de categorização. Existem 5 valores para o primeiro dígito:

SN	Código e Descrição
1	1xx: Informational Isso significa solicitação recebida e processo contínuo.
2	2xx: Success Isso significa que a ação foi recebida, compreendida e aceita com sucesso.
3	3xx: Redirection Isso significa que outras ações devem ser tomadas para concluir a solicitação.
4	4xx: Client Error Isso significa que a solicitação contém sintaxe incorreta ou não pode ser atendida
5	5xx: Server Error O servidor não conseguiu cumprir um pedido aparentemente válido

Os códigos de status HTTP são extensíveis e os aplicativos HTTP não são necessários para compreender o significado de todos os códigos de status registrados. Uma lista de todos os códigos de status foi fornecida em um capítulo separado para sua referência.

Campos de cabeçalho de resposta

Estudaremos o cabeçalho geral e o cabeçalho de entidade em um capítulo separado, quando aprenderemos os campos de cabeçalho HTTP. Por enquanto, vamos verificar o que são campos de cabeçalho de resposta.

Os campos de cabeçalho de resposta permitem que o servidor passe informações adicionais sobre a resposta que não podem ser colocadas na linha de status. Esses campos de cabeçalho fornecem informações sobre o servidor e sobre o acesso posterior ao recurso identificado pelo Request-URI.

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

Você pode introduzir seus campos personalizados no caso de escrever seu próprio cliente e servidor Web personalizados.

Exemplos de mensagens de resposta

Agora, vamos juntar tudo para formar uma resposta HTTP para uma solicitação de busca hello.htm página do servidor da web em execução em 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 seguir está um exemplo de mensagem de resposta HTTP mostrando condição de erro quando o servidor da web não conseguiu encontrar a 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 seguir está um exemplo de mensagem de resposta HTTP mostrando condição de erro quando o servidor da web encontrou uma versão HTTP errada em determinada solicitação HTTP:

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>

O conjunto de métodos comuns para HTTP / 1.1 é definido abaixo e este conjunto pode ser expandido com base no requisito. Esses nomes de método diferenciam maiúsculas de minúsculas e devem ser usados em maiúsculas.

SN	Método e Descrição
1	GET O método GET é usado para recuperar informações de um determinado servidor usando um determinado URI. As solicitações que usam GET devem apenas recuperar dados e não devem ter nenhum outro efeito sobre os dados.
2	HEAD O mesmo que GET, mas apenas transfere a linha de status e a seção do cabeçalho.
3	POST Uma solicitação POST é usada para enviar dados ao servidor, por exemplo, informações do cliente, upload de arquivo, etc., usando formulários HTML.
4	PUT Substitua todas as representações atuais do recurso de destino com o conteúdo carregado.
5	DELETE Remova todas as representações atuais do recurso de destino fornecido pelo URI.
6	CONNECT Estabeleça um túnel para o servidor identificado por um determinado URI.
7	OPTIONS Descreva as opções de comunicação para o recurso de destino.
8	TRACE Execute um teste de loopback de mensagem ao longo do caminho para o recurso de destino.

Método GET

Uma solicitação GET recupera dados de um servidor da web especificando parâmetros na parte do URL da solicitação. Este é o principal método usado para recuperação de documentos. A seguir está um exemplo simples que usa o método GET para buscar 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 seguir, haverá uma resposta do servidor à solicitação GET acima:

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

O método HEAD é funcionalmente como GET, exceto que o servidor responde com uma linha de resposta e cabeçalhos, mas sem corpo de entidade. A seguir está um exemplo simples que usa o método HEAD para buscar informações de cabeçalho 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 seguir, haverá uma resposta do servidor à solicitação GET acima:

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

Você pode notar que aqui o servidor não envia nenhum dado após o cabeçalho.

Método POST

O método POST é usado quando você deseja enviar alguns dados para o servidor, por exemplo, atualização de arquivo, dados de formulário etc. A seguir está um exemplo simples que faz uso do método POST para enviar dados de um formulário ao servidor que serão processados por um process.cgi e finalmente uma resposta será retornada:

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>

O script do lado do servidor process.cgi processa os dados passados e envia a seguinte resposta:

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

O método PUT é usado para solicitar ao servidor que armazene o corpo da entidade incluído em um local especificado pelo URL fornecido. O seguinte exemplo de servidor de solicitação para salvar o determinado corpo de entidade emhello.htm na raiz do 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>

O servidor irá armazenar determinado corpo-entidade em hello.htm arquivo e enviará a seguinte resposta de volta ao 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

O método DELETE é usado para solicitar ao servidor a exclusão do arquivo em um local especificado pelo URL fornecido. O exemplo a seguir solicita ao servidor para excluir o arquivo fornecidohello.htm na raiz do 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

O servidor irá deletar o arquivo mencionado hello.htm e enviará a seguinte resposta de volta ao 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

O método CONNECT é usado pelo cliente para estabelecer uma conexão de rede com um servidor da web por HTTP. O exemplo a seguir solicita uma conexão com um servidor da web em execução no host tutorialspoint.com:

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

A conexão é estabelecida com o servidor e a seguinte resposta é enviada de volta ao cliente:

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

Método OPÇÕES

O método OPTIONS é usado pelo cliente para descobrir quais são os métodos HTTP e outras opções suportadas por um servidor web. O cliente pode especificar um URL para o método OPTIONS ou um asterisco (*) para se referir a todo o servidor. O exemplo a seguir solicita uma lista de métodos suportados por um servidor da web em execução em tutorialspoint.com:

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

O servidor enviará informações com base na configuração atual do servidor, por exemplo:

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

O método TRACE é usado para enviar o conteúdo de uma solicitação HTTP de volta para o solicitante, que pode ser usado para fins de depuração no momento do desenvolvimento. O exemplo a seguir mostra o uso do método TRACE:

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

O servidor enviará a seguinte mensagem em resposta à solicitação acima:

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)

O elemento Status-Code em uma resposta do servidor é um número inteiro de 3 dígitos onde o primeiro dígito do Status-Code define a classe de resposta e os dois últimos dígitos não têm nenhuma função de categorização. Existem 5 valores para o primeiro dígito:

SN	Código e Descrição
1	1xx: Informational Isso significa solicitação recebida e processo contínuo.
2	2xx: Success Isso significa que a ação foi recebida, compreendida e aceita com sucesso.
3	3xx: Redirection Isso significa que outras ações devem ser tomadas para concluir a solicitação.
4	4xx: Client Error Isso significa que a solicitação contém sintaxe incorreta ou não pode ser atendida
5	5xx: Server Error O servidor não conseguiu cumprir um pedido aparentemente válido

Os códigos de status HTTP são extensíveis e os aplicativos HTTP não são necessários para compreender o significado de todos os códigos de status registrados. A seguir está uma lista de todos os códigos de status.

1xx: Informação

Mensagem:	Descrição:
100 continuar	Apenas uma parte da solicitação foi recebida pelo servidor, mas desde que não tenha sido rejeitada, o cliente deve continuar com a solicitação
101 Protocolos de Comutação	O servidor muda o protocolo

2xx: Sucesso

Mensagem:	Descrição:
200 OK	O pedido está OK
201 criado	A solicitação está concluída e um novo recurso é criado
202 aceito	A solicitação foi aceita para processamento, mas o processamento não foi concluído
203 Informações Não Autorizadas	As informações no cabeçalho da entidade são de uma cópia local ou de terceiros, não do servidor original.
204 Sem conteúdo	Um código de status e cabeçalho são fornecidos na resposta, mas não há corpo de entidade na resposta.
205 Redefinir conteúdo	O navegador deve limpar o formulário usado para esta transação para entrada adicional.
206 Conteúdo Parcial	O servidor está retornando dados parciais do tamanho solicitado. Usado em resposta a uma solicitação especificando um cabeçalho Range . O servidor deve especificar o intervalo incluído na resposta com o cabeçalho Content-Range .

3xx: Redirecionamento

Mensagem:	Descrição:
300 Multiple Choices	Uma lista de links. O usuário pode selecionar um link e ir para aquele local. Máximo de cinco endereços
301 mudou-se permanentemente	A página solicitada foi movida para um novo url
302 encontrados	A página solicitada foi movida temporariamente para um novo url
303 Veja outro	A página solicitada pode ser encontrada em um url diferente
304 não modificado	Este é o código de resposta para um cabeçalho If-Modified-Since ou If-None-Match , em que o URL não foi modificado desde a data especificada.
305 Usar proxy	A URL solicitada deve ser acessada por meio do proxy mencionado no cabeçalho Location .
306 não utilizado	Este código foi usado em uma versão anterior. Não é mais usado, mas o código está reservado
307 Redirecionamento Temporário	A página solicitada foi movida temporariamente para um novo url

4xx: Erro do cliente

Mensagem:	Descrição:
400 Bad Request	O servidor não entendeu o pedido
401 não autorizado	A página solicitada precisa de um nome de usuário e uma senha
402 Pagamento Necessário	Você ainda não pode usar este código
403 Proibido	O acesso é proibido à página solicitada
404 não encontrado	O servidor não consegue encontrar a página solicitada
Método 405 não permitido	O método especificado na solicitação não é permitido
406 não aceitável	O servidor só pode gerar uma resposta que não seja aceita pelo cliente
407 Autenticação de proxy necessária	Você deve se autenticar com um servidor proxy antes que esta solicitação possa ser atendida
408 Tempo limite de solicitação	A solicitação demorou mais do que o servidor estava preparado para esperar
409 Conflito	A solicitação não pôde ser concluída devido a um conflito
410 ido	A página solicitada não está mais disponível
411 Comprimento necessário	O "Content-Length" não está definido. O servidor não aceitará o pedido sem ele
412 Falha na pré-condição	A pré-condição fornecida na solicitação avaliada como falsa pelo servidor
413 Solicitação de entidade muito grande	O servidor não aceitará a solicitação, porque a entidade da solicitação é muito grande
414 Request-url muito longo	O servidor não aceitará a solicitação porque o url é muito longo. Ocorre quando você converte uma solicitação "post" em uma solicitação "get" com uma longa informação de consulta
415 Tipo de mídia não suportado	O servidor não aceitará a solicitação, porque o tipo de mídia não é compatível
416 Intervalo solicitado não satisfatório	O intervalo de bytes solicitado não está disponível e está fora dos limites.
417 Falha na expectativa	A expectativa fornecida em um campo de cabeçalho de solicitação Expect não pôde ser atendida por este servidor.

5xx: Erro de servidor

Mensagem:	Descrição:
500 Erro Interno do Servidor	O pedido não foi concluído. O servidor encontrou uma condição inesperada
501 não implementado	O pedido não foi concluído. O servidor não suportou a funcionalidade necessária
502 Bad Gateway	O pedido não foi concluído. O servidor recebeu uma resposta inválida do servidor upstream
503 serviço indisponível	O pedido não foi concluído. O servidor está temporariamente sobrecarregando ou fora do ar
504 Gateway Timeout	O gateway expirou
505 Versão HTTP não suportada	O servidor não suporta a versão "protocolo http"

General-header: Esses campos de cabeçalho têm aplicabilidade geral para mensagens de solicitação e resposta.
Client Request-header: Esses campos de cabeçalho são aplicáveis apenas para mensagens de solicitação.
Server Response-header: Esses campos de cabeçalho são aplicáveis apenas para mensagens de resposta.
Entity-header: Esses campos de cabeçalho definem metainformações sobre o corpo da entidade ou, se nenhum corpo estiver presente

Cabeçalhos Gerais

Cache-control

O campo de cabeçalho geral Cache-Control é usado para especificar as diretivas que DEVEM ser obedecidas por todos os sistemas de cache. A seguir está a sintaxe:

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

Clientes ou servidores HTTP podem usar o Cache-controlcabeçalho geral para especificar parâmetros para o cache ou para solicitar certos tipos de documentos do cache. As diretivas de armazenamento em cache são especificadas em uma lista separada por vírgulas. Por exemplo:

Cache-control: no-cache

Existem seguintes diretivas de solicitação de cache importantes que podem ser usadas pelo cliente em sua solicitação HTTP:

SN	Diretiva e descrição de solicitação de cache
1	no-cache Um cache não deve usar a resposta para satisfazer uma solicitação subsequente sem revalidação bem-sucedida com o servidor de origem.
2	no-store O cache não deve armazenar nada sobre a solicitação do cliente ou a resposta do servidor.
3	max-age = seconds Indica que o cliente está disposto a aceitar uma resposta cuja idade não seja maior que o tempo especificado em segundos.
4	max-stale [ = seconds ] Indica que o cliente está disposto a aceitar uma resposta que excedeu o tempo de expiração. Se segundos forem fornecidos, ele não deve expirar por mais do que esse tempo.
5	min-fresh = seconds Indica que o cliente está disposto a aceitar uma resposta cujo tempo de vida de atualização não seja menor que a idade atual mais o tempo especificado em segundos.
6	no-transform Não converta o corpo-entidade.
7	only-if-cached Não recupere novos dados. O cache pode enviar um documento somente se estiver no cache e não deve contatar o servidor de origem para ver se existe uma cópia mais recente.

Existem a seguir importantes diretivas de resposta de cache que podem ser usadas pelo servidor em sua resposta HTTP:

SN	Diretiva e descrição de solicitação de cache
1	public Indica que a resposta pode ser armazenada em cache por qualquer cache.
2	private Indica que toda ou parte da mensagem de resposta é destinada a um único usuário e não deve ser armazenada em cache por um cache compartilhado.
3	no-cache Um cache não deve usar a resposta para satisfazer uma solicitação subsequente sem revalidação bem-sucedida com o servidor de origem.
4	no-store O cache não deve armazenar nada sobre a solicitação do cliente ou a resposta do servidor.
5	no-transform Não converta o corpo-entidade.
6	must-revalidate O cache deve verificar o status dos documentos desatualizados antes de usá-lo e um que tenha expirado não deve ser usado.
7	proxy-revalidate A diretiva proxy-revalidate tem o mesmo significado que a diretiva must-revalidate, exceto que não se aplica a caches de agentes de usuário não compartilhados.
8	max-age = seconds Indica que o cliente está disposto a aceitar uma resposta cuja idade não seja maior que o tempo especificado em segundos.
9	s-maxage = seconds A idade máxima especificada por esta diretiva substitui a idade máxima especificada pela diretiva max-age ou pelo cabeçalho Expires. A diretiva s-maxage é sempre ignorada por um cache privado.

Conexão

O campo de cabeçalho geral de conexão permite que o remetente especifique as opções desejadas para aquela conexão particular e não deve ser comunicado por proxies em outras conexões. A seguir está a sintaxe simples de usar o cabeçalho de conexão:

Connection : "Connection"

HTTP / 1.1 define a opção de conexão "fechada" para o remetente sinalizar que a conexão será fechada após a conclusão da resposta. Por exemplo:

Connection: Closed

Por padrão, o HTTP 1.1 usa conexões persistentes, onde a conexão não fecha automaticamente após uma transação. O HTTP 1.0, por outro lado, não possui conexões persistentes por padrão. Se um cliente 1.0 deseja usar conexões persistentes, ele usa okeep-alive parâmetro da seguinte forma:

Connection: keep-alive

Encontro

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

Aqui, o primeiro formato é o mais preferido.

Pragma

O campo de cabeçalho geral Pragma é usado para incluir diretivas específicas de implementação que podem ser aplicadas a qualquer destinatário ao longo da cadeia de solicitação / resposta. Por exemplo:

Pragma: no-cache

A única diretiva definida em HTTP / 1.0 é a diretiva no-cache e é mantida em HTTP 1.1 para compatibilidade com versões anteriores. Nenhuma nova diretiva Pragma será definida no futuro.

Reboque

O valor do campo geral Trailer indica que o determinado conjunto de campos de cabeçalho está presente no trailer de uma mensagem codificada com codificação de transferência em partes. A seguir está a sintaxe do campo de cabeçalho do Trailer:

Trailer : field-name

Os campos de cabeçalho de mensagem listados no campo de cabeçalho do trailer não devem incluir os seguintes campos de cabeçalho:

Transfer-Encoding
Content-Length
Trailer

Transfer-Encoding

O campo de cabeçalho geral Transfer-Encoding indica que tipo de transformação foi aplicada ao corpo da mensagem para transferi-la com segurança entre o remetente e o destinatário. Isso não é o mesmo que codificação de conteúdo porque as codificações de transferência são uma propriedade da mensagem, não do corpo da entidade. A seguir está a sintaxe do campo de cabeçalho Transfer-Encoding:

Transfer-Encoding: chunked

Todos os valores de codificação de transferência não diferenciam maiúsculas de minúsculas.

Melhoria

O cabeçalho geral de atualização permite que o cliente especifique quais protocolos de comunicação adicionais ele suporta e gostaria de usar se o servidor achar apropriado para alternar protocolos. Por exemplo:

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

O campo de cabeçalho de atualização se destina a fornecer um mecanismo simples para a transição de HTTP / 1.1 para algum outro protocolo incompatível

Através da

O cabeçalho geral Via deve ser usado por gateways e proxies para indicar os protocolos e destinatários intermediários. Por exemplo, uma mensagem de solicitação pode ser enviada de um agente de usuário HTTP / 1.0 para um proxy interno denominado "fred", que usa HTTP / 1.1 para encaminhar a solicitação para um proxy público em nowhere.com, que conclui a solicitação por encaminhá-lo para o servidor de origem em www.ics.uci.edu. A solicitação recebida por www.ics.uci.edu teria então o seguinte campo de cabeçalho Via:

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

O campo de cabeçalho de atualização se destina a fornecer um mecanismo simples para a transição de HTTP / 1.1 para algum outro protocolo incompatível

Atenção

O cabeçalho geral de Aviso é usado para transportar informações adicionais sobre o status ou transformação de uma mensagem que pode não estar refletida na mensagem. Uma resposta pode conter mais de um cabeçalho de Aviso.

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

Cabeçalhos de solicitação de cliente

Aceitar

O campo Aceitar cabeçalho da solicitação pode ser usado para especificar certos tipos de mídia que são aceitáveis para a resposta. A seguir está a sintaxe geral:

Accept: type/subtype [q=qvalue]

Vários tipos de mídia podem ser listados separados por vírgulas e o qvalue opcional representa um nível de qualidade aceitável para aceitar tipos em uma escala de 0 a 1. A seguir está um exemplo:

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

Isso seria interpretado como text/html e text/x-c são os tipos de mídia preferidos, mas se eles não existirem, envie o text/x-dvi entidade, e se esta não existir, envie o text/plain entidade.

Accept-Charset

O campo de cabeçalho de solicitação Accept-Charset pode ser usado para indicar quais conjuntos de caracteres são aceitáveis para a resposta. A seguir está a sintaxe geral:

Accept-Charset: character_set [q=qvalue]

Vários conjuntos de caracteres podem ser listados separados por vírgulas e o qvalue opcional representa um nível de qualidade aceitável para conjuntos de caracteres não preferidos em uma escala de 0 a 1. A seguir está um exemplo:

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

O valor especial "*", se presente no Accept-Charset campo, corresponde a cada conjunto de caracteres e se não Accept-Charset cabeçalho estiver presente, o padrão é que qualquer conjunto de caracteres seja aceitável.

Aceitar-Codificação

O campo de cabeçalho de solicitação Accept-Encoding é semelhante a Aceitar, mas restringe as codificações de conteúdo que são aceitáveis na resposta. A seguir está a sintaxe geral:

Accept-Encoding: encoding types

A seguir estão alguns exemplos:

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

Accept-Language

O campo de cabeçalho de solicitação Accept-Language é semelhante a Accept, mas restringe o conjunto de linguagens naturais que são preferidas como uma resposta à solicitação. A seguir está a sintaxe geral:

Accept-Language: language [q=qvalue]

Vários idiomas podem ser listados separados por vírgulas e o qvalue opcional representa um nível de qualidade aceitável para idiomas não preferidos em uma escala de 0 a 1. A seguir está um exemplo:

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

Autorização

O valor do campo do cabeçalho de solicitação de autorização consiste em credenciais contendo as informações de autenticação do agente do usuário para a região do recurso que está sendo solicitado. A seguir está a sintaxe geral:

Authorization : credentials

A especificação HTTP / 1.0 define o esquema de autorização BASIC, onde o parâmetro de autorização é a string de username:password codificado na base 64. A seguir está um exemplo:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

O valor decodifica em é guest:guest123 Onde guest é o ID do usuário e guest123 é a senha.

Bolacha

O valor do campo Cookie request-header contém um par nome / valor de informações armazenadas para esse URL. A seguir está a sintaxe geral:

Cookie: name=value

Vários cookies podem ser especificados separados por ponto e vírgula da seguinte forma:

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

Espero

O campo do cabeçalho da solicitação Expect é usado para indicar que comportamentos específicos do servidor são exigidos pelo cliente. A seguir está a sintaxe geral:

Expect : 100-continue | expectation-extension

Se um servidor receber uma solicitação contendo um campo Expect que inclui uma extensão de expectativa não compatível, ele deve responder com um status 417 (Expectation Failed).

De

O campo do cabeçalho da solicitação De contém um endereço de e-mail da Internet para o usuário humano que controla o agente do usuário solicitante. A seguir está um exemplo simples:

From: [email protected]

Este campo de cabeçalho pode ser usado para fins de registro e como um meio de identificar a origem de solicitações inválidas ou indesejadas.

Hospedeiro

O campo de cabeçalho de solicitação do Host é usado para especificar o host da Internet e o número da porta do recurso que está sendo solicitado. A seguir está a sintaxe geral:

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

UMA hostsem nenhuma informação de porta final implica a porta padrão, que é 80. Por exemplo, uma solicitação no servidor de origem para http://www.w3.org/pub/WWW/ seria:

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

If-Match

O campo de cabeçalho de solicitação If-Match é usado com um método para torná-lo condicional. Este cabeçalho solicita que o servidor execute o método solicitado apenas se o valor fornecido nesta tag corresponder às tags de entidade representadas porETag. A seguir está a sintaxe geral:

If-Match : entity-tag

Um asterisco (*) corresponde a qualquer entidade e a transação continua apenas se a entidade existir. A seguir estão alguns exemplos possíveis:

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

Se nenhuma das tags de entidade corresponder, ou se "*" for fornecido e nenhuma entidade atual existir, o servidor não deve executar o método solicitado e deve retornar uma resposta 412 (Falha de pré-condição).

Se-Modificado-Desde

O campo de cabeçalho de solicitação If-Modified-Since é usado com um método para torná-lo condicional. Se a URL solicitada não foi modificada desde o tempo especificado neste campo, uma entidade não será retornada do servidor; em vez disso, uma resposta 304 (não modificada) será retornada sem qualquer corpo de mensagem. A seguir está a sintaxe geral:

If-Modified-Since : HTTP-date

Um exemplo do campo é:

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

If-None-Match

O campo de cabeçalho de solicitação If-None-Match é usado com um método para torná-lo condicional. Este cabeçalho solicita que o servidor execute o método solicitado apenas se um dos valores fornecidos nesta tag corresponder às tags de entidade fornecidas representadas porETag. A seguir está a sintaxe geral:

If-None-Match : entity-tag

Um asterisco (*) corresponde a qualquer entidade e a transação continua apenas se a entidade não existir. A seguir estão alguns exemplos possíveis:

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

If-Range

O campo de cabeçalho de solicitação If-Range pode ser usado com um GET condicional para solicitar apenas a parte da entidade que está faltando, se não tiver sido alterada, e toda a entidade se ela tiver sido alterada. A seguir está a sintaxe geral:

If-Range : entity-tag | HTTP-date

Tanto uma tag de entidade quanto uma data podem ser usadas para identificar a entidade parcial já recebida. Por exemplo:

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

Aqui, se o documento não foi modificado desde a data fornecida, o servidor retorna o intervalo de bytes fornecido pelo cabeçalho Range, caso contrário, ele retorna todo o novo documento.

If-Unmodified-Since

O campo de cabeçalho de solicitação If-Unmodified-Since é usado com um método para torná-lo condicional. A seguir está a sintaxe geral:

If-Unmodified-Since : HTTP-date

Se o recurso solicitado não foi modificado desde a hora especificada neste campo, o servidor deve realizar a operação solicitada como se o cabeçalho If-Unmodified-Since não estivesse presente. Por exemplo:

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

Se a solicitação normalmente resultaria em algo diferente de um status 2xx ou 412, o cabeçalho If-Unmodified-Since deve ser ignorado.

Max-Forwards

O campo de cabeçalho de solicitação Max-Forwards fornece um mecanismo com os métodos TRACE e OPTIONS para limitar o número de proxies ou gateways que podem encaminhar a solicitação para o próximo servidor de entrada. A seguir está a sintaxe geral:

Max-Forwards : n

O valor Max-Forwards é um número inteiro decimal que indica o número restante de vezes que essa mensagem de solicitação pode ser encaminhada. Isso é útil para depuração com o método TRACE, evitando loops infinitos. Por exemplo:

Max-Forwards : 5

O campo de cabeçalho Max-Forwards pode ser ignorado para todos os outros métodos definidos na especificação HTTP.

Autorização Proxy

O campo do cabeçalho de solicitação Proxy-Authorization permite que o cliente se identifique (ou seu usuário) para um proxy que requer autenticação. A seguir está a sintaxe geral:

Proxy-Authorization : credentials

O valor do campo Proxy-Authorization consiste em credenciais contendo as informações de autenticação do agente do usuário para o proxy e / ou domínio do recurso que está sendo solicitado.

Alcance

O campo de cabeçalho de solicitação de intervalo especifica os intervalos parciais do conteúdo solicitado do documento. A seguir está a sintaxe geral:

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

O valor da posição do primeiro byte em uma especificação de intervalo de bytes fornece o deslocamento de byte do primeiro byte em um intervalo. O valor pos do último byte fornece o deslocamento de byte do último byte no intervalo; ou seja, as posições de byte especificadas são inclusivas. Você pode especificar uma unidade de byte como bytes Os deslocamentos de bytes começam em zero. A seguir estão alguns exemplos simples:

- 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

Vários intervalos podem ser listados, separados por vírgulas. Se o primeiro dígito no (s) intervalo (s) de bytes separados por vírgula (s) estiver faltando, o intervalo será considerado contando a partir do final do documento. Se o segundo dígito estiver faltando, o intervalo será o byte n até o final do documento.

Referer

O campo Referer request-header permite que o cliente especifique o endereço (URI) do recurso do qual a URL foi solicitada. A seguir está a sintaxe geral:

Referer : absoluteURI | relativeURI

A seguir está um exemplo simples:

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

Se o valor do campo for um URI relativo, ele deve ser interpretado em relação ao URI de Solicitação .

TE

O campo de cabeçalho de solicitação TE indica qual codificação de transferência de extensão ele está disposto a aceitar na resposta e se está ou não disposto a aceitar campos de trailer em uma codificação de transferência em partes . A seguir está a sintaxe geral:

TE   : t-codings

A presença da palavra-chave "trailers" indica que o cliente está disposto a aceitar campos de trailer em uma codificação de transferência em partes e é especificada de uma das seguintes maneiras:

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

Se o valor do campo TE estiver vazio ou se nenhum campo TE estiver presente, a única codificação de transferência é fragmentada . Uma mensagem sem codificação de transferência é sempre aceitável.

Agente de usuário

O campo de cabeçalho de solicitação do Agente do Usuário contém informações sobre o agente do usuário que originou a solicitação. A seguir está a sintaxe geral:

User-Agent : product | comment

Exemplo:

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

Cabeçalhos de resposta do servidor

Intervalos de aceitação

O campo de cabeçalho de resposta Accept-Ranges permite que o servidor indique sua aceitação de solicitações de intervalo para um recurso. A seguir está a sintaxe geral:

Accept-Ranges  : range-unit | none

Por exemplo, um servidor que aceita solicitações de intervalo de bytes pode enviar

Accept-Ranges: bytes

Os servidores que não aceitam nenhum tipo de solicitação de intervalo para um recurso podem enviar:

Accept-Ranges: none

Isso aconselhará o cliente a não tentar uma solicitação de intervalo.

Era

O campo de cabeçalho de resposta Age transmite a estimativa do remetente da quantidade de tempo desde que a resposta (ou sua revalidação) foi gerada no servidor de origem. A seguir está a sintaxe geral:

Age : delta-seconds

Os valores de idade são inteiros decimais não negativos, representando o tempo em segundos. A seguir está um exemplo simples:

Age: 1030

Um servidor HTTP / 1.1 que inclui um cache deve incluir um campo de cabeçalho Age em cada resposta gerada a partir de seu próprio cache.

ETag

O campo de cabeçalho de resposta ETag fornece o valor atual da tag de entidade para a variante solicitada. A seguir está a sintaxe geral:

ETag :  entity-tag

A seguir estão alguns exemplos simples:

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

Localização

O campo de cabeçalho de resposta de localização é usado para redirecionar o destinatário para um local diferente do URI de solicitação para conclusão. A seguir está a sintaxe geral:

Location : absoluteURI

A seguir está um exemplo simples:

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

O campo de cabeçalho Content-Location difere de Location porque Content-Location identifica o local original da entidade incluída na solicitação.

Proxy-Authenticate

O campo de cabeçalho de resposta Proxy-Authenticate deve ser incluído como parte de uma resposta 407 (Autenticação de proxy necessária). A seguir está a sintaxe geral:

Proxy-Authenticate  : challenge

Tentar novamente depois

O campo de cabeçalho de resposta Retry-After pode ser usado com uma resposta 503 (Serviço Indisponível) para indicar por quanto tempo o serviço ficará indisponível para o cliente solicitante. A seguir está a sintaxe geral:

Retry-After : HTTP-date | delta-seconds

A seguir estão dois exemplos simples:

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

No último exemplo, o atraso é de 2 minutos.

Servidor

O campo de cabeçalho de resposta do servidor contém informações sobre o software usado pelo servidor de origem para lidar com a solicitação. A seguir está a sintaxe geral:

Server : product | comment

A seguir está um exemplo simples:

Server: Apache/2.2.14 (Win32)

Se a resposta estiver sendo encaminhada por meio de um proxy, o aplicativo proxy não deve modificar o cabeçalho de resposta do servidor.

Set-Cookie

O campo de cabeçalho de resposta Set-Cookie contém um par nome / valor de informações a serem retidas para este URL. A seguir está a sintaxe geral:

Set-Cookie: NAME=VALUE; OPTIONS

O cabeçalho de resposta Set-Cookie compreende o token Set-Cookie :, seguido por uma lista separada por vírgulas de um ou mais cookies. Aqui estão os valores possíveis que você pode especificar como opções:

SN	Opções e descrição
1	Comment=comment Esta opção pode ser usada para especificar qualquer comentário associado ao cookie.
2	Domain=domain O atributo Domain especifica o domínio para o qual o cookie é válido.
3	Expires=Date-time A data em que o cookie irá expirar. Se estiver em branco, o cookie irá expirar quando o visitante sair do navegador
4	Path=path O atributo Path especifica o subconjunto de URLs aos quais este cookie se aplica.
5	Secure Isso instrui o agente do usuário a retornar o cookie apenas em uma conexão segura.

A seguir está um exemplo de um cabeçalho de cookie simples gerado pelo servidor:

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

Variar

O campo de cabeçalho de resposta Vary especifica que a entidade tem várias fontes e pode, portanto, variar de acordo com a lista especificada de cabeçalho (s) de solicitação. A seguir está a sintaxe geral:

Vary : field-name

Você pode especificar vários cabeçalhos separados por vírgulas e um valor de asterisco "*" sinaliza que os parâmetros não especificados não se limitam aos cabeçalhos de solicitação. A seguir está um exemplo simples:

Vary: Accept-Language, Accept-Encoding

Aqui, os nomes dos campos não diferenciam maiúsculas de minúsculas.

WWW-Authenticate

O campo de cabeçalho de resposta WWW-Authenticate deve ser incluído nas mensagens de resposta 401 (não autorizado). O valor do campo consiste em pelo menos um desafio que indica o (s) esquema (s) de autenticação e os parâmetros aplicáveis ao URI de solicitação. A seguir está a sintaxe geral:

WWW-Authenticate : challenge

WWW- Authenticate field value, pois pode conter mais de um desafio, ou se mais de um campo de cabeçalho WWW-Authenticate for fornecido, o conteúdo de um desafio pode conter uma lista separada por vírgulas de parâmetros de autenticação. A seguir está um exemplo simples:

WWW-Authenticate: BASIC realm="Admin"

Cabeçalhos de Entidade

Permitir

O campo Permitir cabeçalho de entidade lista o conjunto de métodos suportados pelo recurso identificado pelo URI de Solicitação. A seguir está a sintaxe geral:

Allow : Method

Você pode especificar vários métodos separados por vírgulas. A seguir está um exemplo simples:

Allow: GET, HEAD, PUT

Este campo não pode impedir um cliente de tentar outros métodos.

Codificação de conteúdo

O campo de cabeçalho de entidade Content-Encoding é usado como um modificador para o tipo de mídia. A seguir está a sintaxe geral:

Content-Encoding : content-coding

A codificação de conteúdo é uma característica da entidade identificada pelo Request-URI. A seguir está um exemplo simples:

Content-Encoding: gzip

Se a codificação de conteúdo de uma entidade em uma mensagem de solicitação não for aceitável para o servidor de origem, o servidor deve responder com um código de status 415 (Tipo de mídia não suportado).

Content-Language

O campo de cabeçalho de entidade Content-Language descreve a (s) linguagem (s) natural (is) do público-alvo da entidade incluída. A seguir está a sintaxe geral:

Content-Language : language-tag

Vários idiomas podem ser listados para conteúdo que se destina a vários públicos. A seguir está um exemplo simples:

Content-Language: mi, en

O objetivo principal do Content-Language é permitir que um usuário identifique e diferencie entidades de acordo com o idioma de preferência do usuário.

Comprimento do conteúdo

O campo Content-Length entity-header indica o tamanho do corpo da entidade, em número decimal de OCTETs, enviado ao destinatário ou, no caso do método HEAD, o tamanho do corpo da entidade que teria sido enviado se o pedido foi um GET. A seguir está a sintaxe geral:

Content-Length : DIGITS

A seguir está um exemplo simples:

Content-Length: 3495

Qualquer Content-Length maior ou igual a zero é um valor válido.

Content-Location

O campo de cabeçalho de entidade Content-Location pode ser usado para fornecer a localização do recurso para a entidade incluída na mensagem quando essa entidade está acessível a partir de um local separado do URI do recurso solicitado. A seguir está a sintaxe geral:

Content-Location:  absoluteURI | relativeURI

A seguir está um exemplo simples:

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

O valor de Content-Location também define o URI de base para a entidade.

Content-MD5

O campo de cabeçalho de entidade Content-MD5 pode ser usado para fornecer um resumo MD5 da entidade, para verificar a integridade da mensagem no recebimento. A seguir está a sintaxe geral:

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

A seguir está um exemplo simples:

Content-MD5  : 8c2d46911f3f5a326455f0ed7a8ed3b3

O resumo MD5 é calculado com base no conteúdo do corpo da entidade, incluindo qualquer codificação de conteúdo que foi aplicada, mas não incluindo nenhuma codificação de transferência aplicada ao corpo da mensagem.

Content-Range

O campo de cabeçalho de entidade Content-Range é enviado com um corpo de entidade parcial para especificar onde no corpo de entidade completo o corpo parcial deve ser aplicado. A seguir está a sintaxe geral:

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

Exemplos de valores de especificação de intervalo de conteúdo de byte, supondo que a entidade contenha um 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

Quando uma mensagem HTTP inclui o conteúdo de um único intervalo, esse conteúdo é transmitido com um cabeçalho Content-Range e um cabeçalho Content-Length mostrando o número de bytes realmente transferidos. Por exemplo,

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 conteúdo

O campo de cabeçalho da entidade Content-Type indica o tipo de mídia do corpo da entidade enviado ao destinatário ou, no caso do método HEAD, o tipo de mídia que teria sido enviado se a solicitação fosse um GET. A seguir está a sintaxe geral:

Content-Type : media-type

A seguir está um exemplo:

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

Expira

O campo de cabeçalho de entidade Expires fornece a data / hora após a qual a resposta é considerada obsoleta. A seguir está a sintaxe geral:

Expires : HTTP-date

A seguir está um exemplo:

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

Última modificação

O campo do cabeçalho da entidade Última modificação indica a data e hora em que o servidor de origem acredita que a variante foi modificada pela última vez. A seguir está a sintaxe geral:

Last-Modified: HTTP-date

A seguir está um exemplo:

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

HTTP é normalmente usado para sistemas de informação distribuídos, onde o desempenho pode ser melhorado com o uso de caches de resposta. O protocolo HTTP / 1.1 inclui vários elementos destinados a fazer o cache funcionar.

O objetivo do armazenamento em cache em HTTP / 1.1 é eliminar a necessidade de enviar solicitações em muitos casos e eliminar a necessidade de enviar respostas completas em muitos outros casos.

Os mecanismos básicos de cache em HTTP / 1.1 são diretivas implícitas para caches em que o servidor especifica tempos de expiração e validadores. Nós usamos oCache-Control cabeçalho para esta finalidade.

o Cache-Controlcabeçalho permite que um cliente ou servidor transmita uma variedade de diretivas em solicitações ou respostas. Essas diretivas geralmente substituem os algoritmos de cache padrão. As diretivas de armazenamento em cache são especificadas em uma lista separada por vírgulas. Por exemplo:

Cache-control: no-cache

Existem seguintes diretivas de solicitação de cache importantes que podem ser usadas pelo cliente em sua solicitação HTTP:

SN	Diretiva e descrição de solicitação de cache
1	no-cache Um cache não deve usar a resposta para satisfazer uma solicitação subsequente sem revalidação bem-sucedida com o servidor de origem.
2	no-store O cache não deve armazenar nada sobre a solicitação do cliente ou a resposta do servidor.
3	max-age = seconds Indica que o cliente está disposto a aceitar uma resposta cuja idade não seja maior que o tempo especificado em segundos.
4	max-stale [ = seconds ] Indica que o cliente está disposto a aceitar uma resposta que excedeu o tempo de expiração. Se segundos forem fornecidos, ele não deve expirar por mais do que esse tempo.
5	min-fresh = seconds Indica que o cliente está disposto a aceitar uma resposta cujo tempo de vida de atualização não seja menor que a idade atual mais o tempo especificado em segundos.
6	no-transform Não converta o corpo-entidade.
7	only-if-cached Não recupere novos dados. O cache pode enviar um documento somente se estiver no cache e não deve contatar o servidor de origem para ver se existe uma cópia mais recente.

Existem a seguir importantes diretivas de resposta de cache que podem ser usadas pelo servidor em sua resposta HTTP:

SN	Diretiva de resposta de cache e descrição
1	public Indica que a resposta pode ser armazenada em cache por qualquer cache.
2	private Indica que toda ou parte da mensagem de resposta é destinada a um único usuário e não deve ser armazenada em cache por um cache compartilhado.
3	no-cache Um cache não deve usar a resposta para satisfazer uma solicitação subsequente sem revalidação bem-sucedida com o servidor de origem.
4	no-store O cache não deve armazenar nada sobre a solicitação do cliente ou a resposta do servidor.
5	no-transform Não converta o corpo-entidade.
6	must-revalidate O cache deve verificar o status dos documentos desatualizados antes de usá-lo e um que tenha expirado não deve ser usado.
7	proxy-revalidate A diretiva proxy-revalidate tem o mesmo significado que a diretiva must-revalidate, exceto que não se aplica a caches de agentes de usuário não compartilhados.
8	max-age = seconds Indica que o cliente está disposto a aceitar uma resposta cuja idade não seja maior que o tempo especificado em segundos.
9	s-maxage = seconds A idade máxima especificada por esta diretiva substitui a idade máxima especificada pela diretiva max-age ou pelo cabeçalho Expires. A diretiva s-maxage é sempre ignorada por um cache privado.

URLs HTTP só podem ser enviados pela Internet usando o conjunto de caracteres ASCII , que geralmente contém caracteres fora do conjunto ASCII. Portanto, esses caracteres inseguros devem ser substituídos por um% seguido por dois dígitos hexadecimais.

A tabela a seguir mostra o símbolo ASCII do personagem e seu símbolo igual e finalmente sua substituição que pode ser usada na URL antes de passá-la para o servidor:

ASCII	Símbolo	Substituição
<32		Codifique com% xx, onde xx é a representação hexadecimal do caractere.
32	espaço	+ ou% 20
33	!	% 21
34	"	% 22
35	#	% 23
36	$	% 24
37	%	% 25
38	E	% 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
65	UMA	UMA
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	Eu	Eu
74	J	J
75	K	K
76	eu	eu
77	M	M
78	N	N
79	O	O
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	você	você
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	uma	uma
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	Eu	Eu
106	j	j
107	k	k
108	eu	eu
109	m	m
110	n	n
111	o	o
112	p	p
113	q	q
114	r	r
115	s	s
116	t	t
117	você	você
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 com% xx onde xx é a representação hexadecimal do caractere

O HTTP é usado para comunicação pela Internet, portanto, desenvolvedores de aplicativos, provedores de informações e usuários devem estar cientes das limitações de segurança do HTTP / 1.1. Esta discussão não inclui soluções definitivas para os problemas mencionados aqui, mas faz algumas sugestões para reduzir os riscos de segurança.

Vazamento de informações pessoais

Os clientes HTTP costumam ter acesso a grandes quantidades de informações pessoais, como nome do usuário, localização, endereço de e-mail, senhas, chaves de criptografia, etc. Portanto, você deve ter muito cuidado para evitar o vazamento não intencional dessas informações por meio do protocolo HTTP para outras fontes.

Todas as informações confidenciais devem ser armazenadas no lado do servidor de forma criptografada.
Revelar a versão específica do software do servidor pode permitir que a máquina do servidor se torne mais vulnerável a ataques contra software que é conhecido por conter brechas de segurança.
Os proxies que funcionam como um portal através de um firewall de rede devem tomar precauções especiais com relação à transferência de informações de cabeçalho que identificam os hosts atrás do firewall.
As informações enviadas no campo De podem entrar em conflito com os interesses de privacidade do usuário ou com a política de segurança de seu site e, portanto, não devem ser transmitidas sem que o usuário seja capaz de desativar, ativar e modificar o conteúdo do campo.
Os clientes não devem incluir um campo de cabeçalho Referer em uma solicitação HTTP (não segura) se a página de referência foi transferida com um protocolo seguro.
Autores de serviços que usam o protocolo HTTP não devem usar formulários baseados em GET para o envio de dados confidenciais, porque isso fará com que esses dados sejam codificados no URI de Solicitação

Ataque baseado em nomes de arquivo e caminho

O documento deve ser restrito aos documentos retornados por solicitações HTTP para serem apenas aqueles que foram pretendidos pelos administradores do servidor.

Por exemplo, UNIX, Microsoft Windows e outros sistemas operacionais usam ..como um componente de caminho para indicar um nível de diretório acima do atual. Em tal sistema, um servidor HTTP DEVE desautorizar qualquer construção no Request-URI se, de outra forma, permitir o acesso a um recurso fora daqueles que deveriam ser acessados através do servidor HTTP.

Spoofing de DNS

Os clientes que usam HTTP dependem muito do Serviço de Nomes de Domínio e, portanto, geralmente estão sujeitos a ataques de segurança com base na má associação deliberada de endereços IP e nomes DNS. Portanto, os clientes precisam ser cautelosos ao assumir a validade contínua de uma associação de número IP / nome DNS.

Se os clientes HTTP armazenam em cache os resultados das pesquisas de nome de host para obter uma melhoria de desempenho, eles devem observar as informações de TTL relatadas pelo DNS. Se os clientes HTTP não observarem essa regra, eles podem ser falsificados quando o endereço IP de um servidor acessado anteriormente é alterado.

Cabeçalhos de localização e spoofing

Se um único servidor oferece suporte a várias organizações que não confiam umas nas outras, ele DEVE verificar os valores dos cabeçalhos Localização e Conteúdo-Localização nas respostas que são geradas sob o controle dessas organizações para se certificar de que não tentam invalidar recursos sobre os quais eles não têm autoridade.

Credenciais de autenticação

Clientes HTTP e agentes de usuário existentes normalmente retêm informações de autenticação indefinidamente. HTTP / 1.1. não fornece um método para um servidor direcionar os clientes a descartarem essas credenciais em cache, o que é um grande risco de segurança.

Existem várias soluções alternativas para partes desse problema e, portanto, é recomendado fazer o uso de proteção por senha em protetores de tela, tempos limite de ociosidade e outros métodos que atenuem os problemas de segurança inerentes a esse problema.

Proxies e Cache

Os proxies HTTP são intermediários e representam uma oportunidade para ataques intermediários. Os proxies têm acesso a informações relacionadas à segurança, informações pessoais sobre usuários individuais e organizações e informações proprietárias pertencentes a usuários e provedores de conteúdo.

Os operadores de proxy devem proteger os sistemas nos quais os proxies são executados, pois protegem qualquer sistema que contenha ou transporte informações confidenciais.

Os proxies de cache fornecem vulnerabilidades potenciais adicionais, uma vez que o conteúdo do cache representa um alvo atraente para exploração maliciosa. Portanto, o conteúdo do cache deve ser protegido como informação sensível.

Exemplo 1

Solicitação HTTP para buscar hello.htmpágina do servidor da web em execução em tutorialspoint.com

Pedido do 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

Resposta do 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>

Exemplo 2

Solicitação HTTP para buscar t.htmlpágina que não existe no servidor da web em execução em tutorialspoint.com

Pedido do 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

Resposta do 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>

Exemplo 3

Solicitação HTTP para buscar hello.htmpágina do servidor da web em execução em tutorialspoint.com , mas a solicitação segue com a versão HTTP errada:

Pedido do 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

Resposta do 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>

Exemplo 4

Solicitação HTTP para postar dados do formulário para process.cgiPágina CGI em um servidor da web em execução em tutorialspoint.com . O servidor retorna o nome passado após defini-los como cookies:

Pedido do 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

Resposta do 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>