Não é realmente necessário entender o HTTP para criar aplicações web, mas é interessante que se tenha uma visão geral do mesmo para projetar aplicações mais robustas e saber como contornar suas limitações. Não espere se tornar um mestre do protocolo lendo esse texto, mas também não espere que esse seja um texto introdutório para que você aprenda a implementar o protocolo. Meu único objetivo aqui é destacar algumas peculiaridades do HTTP. Caso queira um conhecimento mais profundo, comece pela RFC2616.

HTTP é um protocolo cliente-servidor baseado em mensagens usado para obtenção de entidades. A responsabilidade do servidor é responder as mensagens de requisição e um mesmo servidor pode servir diferentes recursos.

Cada mensagem HTTP é composta de uma linha inicial, que depende do tipo de mensagem (requisição ou resposta), um conjunto de linhas de cabeçalho, que compõem os metadados da mensagem, e o corpo da mensagem, que carrega uma entidade.

As mensagens HTTP possuem algumas propriedades. Quero que você, durante a leitura desse texto, esteja ciente das seguintes:

• Existe um verbo associado a cada mensagem de requisição.
  
  As mensagens de requisição mais comuns utilizam o método GET, que em condições normais não modifica o recurso-alvo, mas outros métodos existem, sejam eles definidos no RFC2616 ou criados por aplicações específicas como o Subversion. Alguns deles são:
  • GET: Requisita uma entidade identificada pelo recurso indicado.
  • HEAD: Permite obter os metadados da mensagem sem obter a entidade.
  • POST: Permite que o cliente envie dados (uma imagem, um texto, ...) para o servidor.
  
  
• O cliente pode enviar mensagens ao servidor, mas o contrário não acontece.
  
  Mesmo que a conexão já tenha sido iniciada pelo cliente. Para contornar o problema existem várias soluções, cada uma com diferentes desvantagens. Para resolver o problema foi desenvolvido o protocolo WebSocket, para ser usado em conjunto com a capacidade do HTTP de atualizar o protocolo em uso por uma conexão já em andamento.
  
  
• Para cada conexão com um servidor, só uma mensagem de requisição pode ser enviada por vez.
  
  Isso não significa que o cliente deve esperar pela resposta da primeira mensagem antes de fazer a segunda requisição, mas que duas mensagens não podem ser embaralhadas. Caso fosse possível, o servidor poderia responder as mensagens em qualquer ordem, que seria um recurso interessante para ter um melhor aproveitamento de rede em casos onde uma requisição específica demanda um tempo maior para ser respondida.
  
  
• O corpo de uma mensagem nem sempre é igual à entidade a ela associada.
  
  Algumas vezes são aplicadas transformações, que podem adicionar alguns benefícios:
  • Compressão, permitindo um melhor uso do tráfego de rede. Atualmente não é suportado de forma transparente pelo Tufão, mas planejado para a versão 0.4.
  • Quebra da mensagem em chunks. No protocolo HTTP/1.0, era necessário que o servidor enviasse o tamanho do corpo da mensagem antes da mensagem, o que dificultava o uso do protocolo para enviar dados que ainda estavam sendo gerados. Usar o protocolo para transmissão ao vivo, por exemplo, seria uma péssima ideia.
  
  

Para obter a página inicial da Wikipédia, por exemplo, a seguinte mensagem de requisição seria enviada:

GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org
Connection: close

A mensagem de requisição possui uma linha inicial conhecida como request line, que indica, além do método, o recurso desejado e a versão HTTP suportada.

O começo da mensagem de resposta para a requisição acima, no momento em que fiz a requisição, foi:

HTTP/1.0 200 OK
Date: Sun, 27 May 2012 20:50:07 GMT
Server: Apache
X-Content-Type-Options: nosniff
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: en
Vary: Accept-Encoding,Cookie
Last-Modified: Sun, 27 May 2012 20:10:23 GMT
Content-Length: 59587
Content-Type: text/html; charset=UTF-8
X-Cache: MISS from cp1007.eqiad.wmnet
X-Cache-Lookup: MISS from cp1007.eqiad.wmnet:3128
Age: 665
X-Cache: HIT from cp1004.eqiad.wmnet
X-Cache-Lookup: HIT from cp1004.eqiad.wmnet:80
Connection: close

A primeira linha da mensagem de resposta é chamada de status line e indica a validade da requisição. Isso é, se o recurso requisitado foi encontrado ou não, se o intervalo requisitado é satisfazível, entre outros. Os códigos mais comuns são "200 OK", usado quando não há erros, e "404 Not Found", usado quando não existe uma entidade associada ao recurso requisitado pelo cliente.

Grande parte desses cabeçalhos não deve mudar entre a maior parte das páginas da Wikipédia, mas a principal mudança deve ocorrer no recurso requisitado (nesse caso /wiki/Main_Page) e no corpo da mensagem de resposta (omitido nesse caso).

Os cabeçalhos em uma mensagem construídos na forma "Chave: valor", com a chave sendo insensível a capitalização e podendo existir espaços arbitrariamente entre os elementos.

O cabeçalho Host é obrigatório no HTTP/1.1 e foi criado para permitir Virtual Hosting.

Cada cabeçalho tem um significado definido e implementações costumam simplesmente ignorar cabeçalhos desconhecidos ou não implementados.

O Tufão vai cuidar dos principais cabeçalhos e comportamentos para você, exigindo que você examine-os somente em casos especiais e foque sua atenção na construção das páginas.