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