Introdução ao protocolo HTTP (por Bruno Torres)

Esse é o primeiro texto de uma série que pretendo escrever, explicando o básico sobre os conceitos
e tecnologias que formam o que chamamos de web, e que vou chamar pelo criativo nome de “O
básico da web”. Pra muitos de vocês a informação apresentada aqui (e nos textos seguintes) vai
parecer trivial, básico demais pro seu gosto. Mas, com certeza, para muitos outros pode ser
realmente útil. O feedback de vocês é apreciado e pode nortear o desenvolvimento dos próximos
textos. Vamos então ao que interessa. Nada mais justo que começar essa série de textos dando uma
noção do protocolo HTTP, que é, de fato, a base sobre a qual a web se sustenta. Qualquer um que
deseje publicar qualquer tipo de recurso na web deve ter pelo menos algum conhecimento , ainda
que básico, de HTTP. Principalmente hoje, com a popularização do AJAX, que consiste
basicamente de requisições HTTP. HTTP é um protocolo, uma série de regras que definem como
um determinado diálogo deve ser conduzido. Basicamente o protocolo define que perguntas podem
ser feitas, e que respostas podem ser dadas a cada uma delas. Nesse diálogo, quem faz as perguntas
(ou requisições) é o cliente HTTP — também chamado de user agent, que pode ser um browser, um
robô (googlebot é um exemplo), um leitor de tela, um script, ou qualquer outro programa que
conheça e saiba como seguir o protocolo. Quem dá as respostas é o servidor HTTP (ou servidor
web). Os dois servidores HTTP que dominam a quase totalidade do mercado hoje em dia são o
Apache, da Apache Foundation e o IIS, da microsoft. Nos últimos tempos o lighthttpd vem
ganhando alguma força, apoiado no crescente sucesso da linguagem de programação Ruby e seu
quase ubíquo companheiro Rails. Nota: A não ser quando notado o contrário, todas as
implementações e códigos exibidos nesse texto e nos subseqüentes referentes a HTTP serão
baseados no servidor Apache.

O diálogo

E como é esse tal diálogo, regido pelo protocolo HTTP? Bom, existem muitas possibilidades de
perguntas e respostas em um diálogo HTTP. Vamos dar uma olhada em uma conversa bem básica e,
aos poucos, vamos aumentando a complexidade. Uma requisição HTTP comum é algo muito
parecido com isso:

GET / HTTP/1.1
Host: dominio.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915 Firefox/1.0.7
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,
image/png,*/*;q=0.5

Na primeira linha, o cliente informa ao servidor que ele deseja a raiz do site (/), que o método usado
para “pegar” este recurso é o GET (que será explicado mais a frente) e que o protocolo usado é o
HTTP versão 1.1. A partir da segunda linha começam os request headers. O primeiro deles informa
o host onde o recurso se encontra, na segunda o user agent se identifica (no caso acima é o Firefox
1.0.7) e na terceira diz que tipo de recursos está apto a receber e interpretar de maneira correta. Isso
é suficiente para o servidor buscar o recurso e enviar uma resposta ao cliente. Vamos explorar
melhor os códigos de resposta nos próximos textos. Por agora, vamos ver como poderia ser uma
resposta à requisição acima, caso o recurso fosse encontrado pelo servidor:

HTTP/1.x 200 OK
Date: Mon, 12 Dec 2005 04:15:03 GMT
Server: Apache/1.3.33 (Unix) DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1a
PHP/4.3.10 mod_ssl/2.8.22 OpenSSL/0.9.7e
Content-Type: text/html; charset=UTF-8
Com isso o servidor diz ao cliente que a requisição teve sucesso e o recurso foi encontrado (200
OK), informa a data e hora, se identifica e mostra que tipo de documento está sendo enviado e qual
o seu charset (conjunto de caracteres, assunto que também será tratado mais a frente). Essa resposta
é enviada ao cliente acompanhada do conteúdo do recurso requisitado. No caso um documento
HTML. Como já disse acima, existem inúmeras possibilidades para as perguntas e respostas em um
diálogo HTTP. Esse texto foi apenas uma introdução ao protocolo. Você pode “bisbilhotar” os
diálogos HTTP que acontecem enquanto você navega usando a extensão Live HTTP Headers para o
Firefox. Vá brincando com ela enquanto espera o próximo texto: Códigos de resposta e seus
significados.

Protocolo HTTP: métodos de requisição

O método de requisição é o primeiro dado enviado pelo user-agent ao fazer uma requisição HTTP
ao servidor.

Vamos usar o código de exemplo do post de introdução ao protocolo HTTP.

Vejamos a primeira linha de uma requisição HTTP de exemplo: GET / HTTP/1.1

Essa linha informa que a requisição se trata de uma recuperação de dados (método GET), usando o
protocolo HTTP, versão 1.1. Esse método, GET, é justamente o primeiro de que vamos tratar,
principalmente pelo fato de ser ele o método usado como padrão por qualquer user-agent e, por
isso, ser, de longe, o método mais usado. O método GET tem duas propriedades importantes: deve
ser seguro (safe) e idempotente (idempotent).

Ser seguro significa que o método não deve ser usado para produzir mudanças nos dados que estão
no servidor. Ou seja, nunca se deve usar o método GET para, por exemplo, atualizar um dado em
um banco de dados.

Idempotente quer dizer que múltiplas requisições ao mesmo recurso usando o método devem ter o
mesmo resultado que teria uma requisição apenas. A título de curiosidade, idempotente é a
propriedade de um número que, multiplicado por ele mesmo, tem ele mesmo como resultado (n x n
= n), em termos de números reais, apenas 0 e 1 têm essa propriedade.

Em termos de métodos de requisição HTTP, os métodos GET, HEAD, PUT e DELETE são os que
possuem a propriedade de ser idempotentes. Claro que há exceções. Por exemplo, digamos que o
recurso requisitado seja a home page de um blog, que mostra os posts e o número de comentários
submetidos em cada um. Se, ao mesmo tempo que você faz suas requisições GET um outro usuário
postar um comentário ou mesmo o autor do blog postar um novo texto, o resultado da requisição
será diferente.

O que não pode acontecer é as suas requisições resultarem em mudanças no conteúdo da resposta.
A função do método GET é pura e simplesmente recuperar um recurso existente no servidor. O
resultado de uma requisição GET é “cacheável” pelo cliente.

Ou seja, se o seu browser possui a capacidade de guardar cópias das páginas visitadas para uso
posterior, ou seja, tem cache, após uma requisição GET bem sucedida, o conteúdo da resposta
(headers e corpo) serão guardados neste cache e em uma requisição posterior ao mesmo recurso,
caso sejam verificadas algumas condições (que veremos quando formos falar especificamente sobre
cache), não será necessário baixar novamente todo o conteúdo do recurso. A versão em cache é
usada. Você estará usando o método GET quando:

• Digitar uma URL na barra de endereços do seu browser e apertar Enter

 • Seguir um link em uma página na web, email, programa externo ou nos bookmarks
(favoritos) do seu browser
• Submeter, em uma página web, um formulário cujo método seja get (method="get")

No caso de formulários HTML, cabe aqui uma observação: caso o método do formulário seja GET,
as informações submetidas estarão explicitamente expostas ao usuário por meio de uma query
string na URL que aparecerá na barra de endereços do browser. Além disso, deve-se tomar cuidado
com formulários usando esse método porque, caso a quantidade de informação submetida seja
grande demais, pode resultar em problemas em alguns user-agents que, por questões de segurança,
limitam o tamanho de URL que pode ser aceito. A especificação oficial do método GET pode ser
lida (em inglês) na página de definição dos métodos HTTP, no site do W3C.

Protocolo HTTP: códigos de resposta mais comuns e seus significados

No texto anterior, “Introdução ao HTTP” vimos de uma maneira bem básica o que é o HTTP e
como se dá um diálogo entre cliente e servidor. Se você não o leu, leia. Pode ir lá ler que eu
espero… Ok, vamos continuar. A requisição ilustrada no último texto era a seguinte:

GET / HTTP/1.1
Host: dominio.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915 Firefox/1.0.7
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,
image/png,*/*;q=0.5

Ao receber essa requisição, o servidor procura pelo recurso requisitado e envia uma resposta ao
cliente. Essa resposta contém um código de resposta, que consiste de um número e uma pequena
descrição padrão do código. São vários os códigos possíveis, mas por enquanto vamos dar uma
olhada nos mais comuns. Os códigos de resposta seguem a seguinte numeração: começados com 1
(1XX), que são códigos informativos; 2XX, que indicam sucesso; 3XX que reportam um
redirecionamento; 4XX, que informam erros acontecidos no cliente e 5XX, erros no servidor. Não
vou tratar de nenhum código 1XX nesse texto. Por dois motivos: eles não são muito comuns e
porque, devo confessar, não os conheço muito bem a ponto de escrever sobre. Nota: Perceba que
estamos assumindo uma requisição GET básica. A coisa nem sempre é tão simples e, dependendo
do método, o significado e as ações que devem ser tomadas pelo cliente diante de alguns códigos de
resposta podem ser um pouco diferentes. Requisições mais complexas serão cobertas em textos
futuros. Vamos aos códigos:

200 OK

Como o nome já diz, esse código informa que a requisição teve sucesso e está tudo Ok. Junto com
este código o servidor deve enviar, acompanhado de alguns headers, o conteúdo do recurso
requisitado que pode ser, por exemplo, um documento HTML ou XML , uma imagem JPEG ou
GIF, etc. Spec do código 200.

302 Found

Este é o código de redirecionamento mais comum. Ele descreve um redirecionamento temporário,

ou seja, pode ser que numa próxima requisição esse redirecionamento não seja necessário. Ao
receber um código 302, o cliente deve procurar pelo header “Location”, que deve informar a URI
para a qual o recurso está sendo redirecionado. Em acessos futuros, a URI original deve ser
requisitada novamente e o redirecionamento deve ser feito , caso seja necessário. Spec do código
302.

301 Moved Permanently

O recurso foi permanentemente movido para um outro local. Ao receber este código o cliente deve
procurar pelo header “Location” e requisitar a URI nele informada. Acessos futuros devem
requisitar a nova URL (contida no Location) já que o recurso foi movido de maneira permanente. A
URI original deve ser apagada de qualquer registro existente no cliente. Spec do código 301.

304 Not Modified

Esse código é usado quando o cliente faz uso de caching, ou seja, guarda cópias locais dos recursos
acessados. Ele informa ao cliente que o recurso não foi modificado desde a última requisição e que
a versão guardada em cache pode ser usada. Os mecanismos envolvidos no processo de caching vão
ser discutidos posteriormente. Por enquanto você pode dar uma lida no Tutorial sobre Caching do
Mark Nottingham. Spec do código 304.

404 Not Found

Este código informa ao cliente que o recurso não foi encontrado no servidor. Pode ser que o recurso
realmente não exista ou apenas esteja temporariamente indisponível. Pode ser que o usuário tenha
cometido um erro ao digitar a URI ou simplesmente o servidor não queira revelar o que realmente
aconteceu. Se o cliente guardar as URIs acessadas para referências futuras (como no caso do
histórico de um browser), nenhuma ação deve ser tomada e a URI deve ser mantida, pois pode ser
que o recurso esteja disponível em uma próxima requisição. Spec do código 404.

410 Gone

O código 410 informa que o recurso requisitado não existe mais, ou seja, foi intencionalmente
removido do servidor e não há endereço para redirecionamento. De acordo com a especificação,
esse estado deve ser considerado permanente. Infelizmente, na maioria das implementações, esse
código não é usado, e o servidor envia um código 404 em seu lugar. Ao receber um código 410, o
cliente — se tiver essa capacidade — deve remover qualquer referência ao respectivo recurso. Mark
Pilgrim escreveu um texto excelente sobre o assunto, há algum tempo. Spec do código 410.

403 Forbidden

Você está mexendo onde não deve, rapaz! Esse código informa que você simplesmente não pode
acessar o recurso requisitado. Nem mesmo é possível acessar o recurso por meio de autenticação.
Esqueça, acesso negado. Ponto. Spec do código 403.

401 Unauthorized

Nesse caso o recurso pode ser acessado, desde que você possua as informação de autenticação
corretas (usuário e senha) para acessá-lo, o que parece não ser verdade, já que você recebeu esse
código. Spec do código 401.

500 Internal Server Error

Esse erro é bastante comum. Ele informa que algo de inesperado (ou simplesmente algo que ele não
quer te contar) aconteceu no servidor e a sua requisição não pôde ser satisfeita. Spec do código 500.

502 Bad Gateway

Esse erro é muito comum no GMail. Significa que o servidor que você acessou atua como um proxy
ou gateway e que o servidor “acima” dele reportou algum erro ao tentar completar a requisição.
Spec do código 502.

503 Service Unavailable

O recurso está temporariamente indisponível. Este erro pode ser causado por sobrecarga no servidor
ou por alguma operação de manutenção. Espere e tente novamente mais tarde. Spec do código 503.
Bom, esses são os códigos de resposta mais comuns definidos pelo protocolo HTTP. Existem vários
outros, que podem ser vistos na seção 10 da especificação do protocolo. Se você estiver
implementando um cliente HTTP (uma aplicação em AJAX, por exemplo), lembre-se de
considerar, pelo menos, a possibilidade de receber os códigos listados aqui, já que, muito
provavelmente, mais cedo ou mais tarde, eles vão aparecer e você deve estar preparado. No
próximo texto: Métodos de requisição.

Termos e definições
HTTP
Hypertext Transfer Protocol (Protocolo de transferência de Hipertexto).
Protocolo criado para possibilitar o tráfego de informações com hipertexto na web. Veja o
post Introdução ao HTTP.
Hipertexto
Texto que contém internamente referências a outros textos ou documentos. Na web, o que
caracteriza essas referências são os hiperlinks, ou simplesmente links.
User agent
Uma aplicação que age como cliente em uma transação cliente-servidor feita sobre um
determinado protocolo de rede. Na web esse protocolo é o HTTP e os user-agents são os
browsers, crawlers, dispositivos móveis, leitores de tela, painéis em braile e qualquer outra
aplicação usada por um usuário para navegar por páginas web.
Crawler (ou spider, ou robot)
Qualquer aplicação cuja função principal seja navegar automaticamente por páginas na web,
seguindo hiperlinks (e usando os conteúdos dessa página para algum fim, como salvar seu
conteúdo, ou retirar dele alguma informação específica). O exemplo clássico de crawler são
os programas usados por sistemas de busca (como o Google) para indexar páginas na web.
Hiperlink (ou simplesmente link)
Elemento básico do hipertexto, um link caracteriza uma referência a um documento externo.
Em HTML, os links são definidos usando o elemento A que contém a referência, no caso
uma URI, em seu atributo HREF
URI
Uniform Resource Identifier (Identificador Unificado de Recurso)
É, basicamente, uma string (conjunto de caracteres) que seguem uma certa sintaxe e é usado
para definir identificar um recurso na web. O tipo mais comum de URI é a URL
URL
Uniform Resource Locator (Localizador Unificado de Recurso)
Um tipo específico de URI, usado para definir a localização de um recurso na web.
Geralmente dizemos que a URL é o endereço de uma página web. Um exemplo de URL:
http://www.exemplo.com/pagina/
HTML
 Hypertext Markup Language (Linguagem de marcação de hipertexto)
Linguagem marcação (que contém elementos que delimitam um determinado conteúdo para
definir o seu papel ou significado dentro do texto) usada para estruturar páginas web.

Postado por Bruno Torres em 4 Mai 2006