Mensagens HTTP

Requisições HTTP são mensagens enviadas pelo cliente para iniciar uma ação no servidor. Suas linhas iniciais contêm três elementos:

1. Um método HTTP, um verbo (como GET, PUT ou POST) ou um nome (como HEAD ou OPTIONS), que descrevem a ação a ser executada. Por exemplo, GET indica que um recurso deve ser obtido ou POST significa que dados são inseridos no servidor (criando ou modificando um recurso, ou gerando um documento temporário para mandar de volta).

2. O alvo da requisição, normalmente um URL, ou o caminho absoluto do protocolo, porta e domínio são em geral caracterizados pelo contexto da requisição. O formato deste alvo varia conforme o método HTTP. Pode ser

   • Um caminho absoluto, seguido de um '?' e o texto da consulta. Esta é a forma mais comum, conhecida como a forma original, e é usada com os métodos GET, POST, HEAD, e OPTIONS. POST / HTTP/1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0
   • Uma URL completa, conhecida como a forma absoluta, usada principalmente com GET quando conectado a um proxy. GET http://developer.mozilla.org/pt-BR/docs/Web/HTTP/Messages HTTP/1.1
   • O componente autoridade de um URL, que consiste no nome do domínio e opcionalmente uma porta (prefixada por ':'), chamada de forma autoridade. Só usada com CONNECT ao estabelecer um túnel HTTP. CONNECT developer.mozilla.org:80 HTTP/1.1
   • A forma asterisco, um simples asterisco ('*'), usada com OPTIONS. Representa o servidor como um todo. OPTIONS * HTTP/1.1

3. A versão HTTP, que define a estrutura do restante da mensagem, atuando como um indicador da versão esperada para uso na resposta.

Cabeçalhos HTTP de uma requisição seguem a mesma estrutura básica de um cabeçalho HTTP: uma cadeia de caracteres insensível à caixa seguida de dois pontos (':') e um valor cuja estrutura depende do cabeçalho. O cabeçalho inteiro, incluindo o valor, consiste em uma única linha, que pode ser bem grande.

Há numerosos cabeçalhos de requisição disponíveis. Eles podem ser divididos em vários grupos:

• Cabeçalhos gerais, como Via, se aplicam à mensagem como um todo.
• Cabeçalhos de requisição, como User-Agent, Accept-Type, modificam a requisição, especificando-a mais (como Accept-Language), dando-a contexto (como Referer), ou restringindo-a condicionalmente (como If-None).
• Cabeçalhos de entidade, como Content-Length que se aplicam ao corpo da mensagem. Obviamente este cabeçalho não será transmitido se não houver corpo na requisição.

A parte final da requisição é o corpo. Nem todas as requisições tem um: as que pegam recursos, como GET, HEAD, DELETE, ou OPTIONS, usualmente não precisam de um. Algumas requisições enviam dados ao servidor a fim de atualizá-lo: é o caso frequente de requisições POST (contendo dados de formulário HTML).

Corpos podem ser divididos, a grosso modo, em duas categorias:

• Corpos de recurso-simples, consistindo em um único arquivo, definido pelos dois cabeçalhos: Content-Type e Content-Length.
• Corpos de recurso-múltiplo, consistindo em um corpo de múltiplas partes, cada uma contendo uma porção diferente de informação. Este é tipicamente associado à Formulários HTML.

A linha inicial de uma resposta HTTP, chamada de linha de status, contém a seguinte informação:

1. A versão do protocolo, normalmente HTTP/1.1.
2. Um código de status, indicando o sucesso ou falha da requisição. Códigos de status comuns são 200, 404, ou 302
3. Um texto de status. Uma descrição textual breve, puramente informativa, do código de status a fim de auxiliar o entendimento da mensagem HTTP por humanos.

Uma linha de status típica se parece com: HTTP/1.1 404 Not Found.

Cabeçalhos HTTP para respostas seguem a mesma estrutura de qualquer outro cabeçalho: uma cadeia de caracteres insensível à caixa seguida de dois pontos (':') e um valor cuja estrutura depende do tipo de cabeçalho. O cabeçalho inteiro, incluindo o valor, consiste em uma única linha.

Há numerosos cabeçalhos de resposta disponíveis. Eles podem ser divididos em vários grupos:

• Cabeçalhos gerais, como Via, aplicam-se à toda mensagem.
• Cabeçalhos de resposta, como Vary e Accept-Ranges, dão informação adicional sobre o servidor, que não cabe na linha de status.
• Cabeçalhos de entidade, como Content-Length, aplicam-se ao corpo da resposta. Obviamente este cabeçalho não será transmitido se não houver corpo na resposta.

A última parte de uma resposta é o corpo. Nem toda resposta tem um: aquelas com código de status 201 ou 204 normalmente não tem.

Corpos podem ser divididos, a grosso modo, em três categorias:

• Corpos de recurso simples que consistem em um único arquivo de tamanho conhecido, definido pelos dois cabeçalhos: Content-Type e Content-Length.
• Corpos de recurso simples que consistem em um único arquivo de tamanho desconhecido, codificado aos pedaços com Transfer-Encoding ajustado para chunked.
• Corpos de recurso múltiplo, que consiste em um corpo com múltiplas partes, cada uma contendo diferentes seções de informação. Estes são relativamente raros.

Mensagens HTTP/1.x têm algumas desvantagens quanto ao desempenho:

• Os cabeçalhos, ao contrário dos corpos, não são compactados.
• Cabeçalhos com frequência são similares entre uma mensagem e a seguinte, ainda assim são repetidos entre conexões.
• Nenhuma multiplexação pode ser feita. É necessário abrir várias conexões no mesmo servidor: e conexões TCP quentes são mais eficientes que frias.

HTTP/2 introduz um passo extra: ele divide mensagens HTTP/1.x em quadros que são embutidos em um fluxo. Quadros de dados e de cabeçalho são separados, isto permite a compressão do cabeçalho. Muitos fluxos podem ser conjugados, um processo chamado de multiplexação, permitindo mais eficiência nas conexões TCP subjacentes.

Connection

Quadros HTTP agora são transparentes aos desenvolvedores web. Isso é um passo adicional no HTTP/2, entre mensagens HTTP/1.1 e o protocolo de transporte subjacente. Nenhuma mudança é necessária nas API usadas pelo desenvolvedor web para utilizar quadros; quando disponível tanto no navegador quanto no servidor, HTTP/2 é ativado e usado.

Mensagens HTTP são a chave ao usar HTTP; sua estrutura é simples e elas são altamente extensíveis. O mecanismo de enquadramento do HTTP/2 adiciona uma nova camada intermediária entre a sintaxe HTTP/1.x e o protocolo de transporte subjacente, sem modificá-lo fundamentalmente: construído sobre mecanismos provados.