Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Look up keyword
Like this
0Activity
0 of .
Results for:
No results containing your search query
P. 1
Introducao ao protocolo HTTP

Introducao ao protocolo HTTP

Ratings:

5.0

(2)
|Views: 2,308|Likes:
Published by Pedro Correia

More info:

Categories:Types, School Work
Published by: Pedro Correia on Aug 10, 2008
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/22/2013

pdf

text

original

 
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 conceitose tecnologias que formam o que chamamos de web, e que vou chamar pelo criativo nome de “Obásico da web”. Pra muitos de vocês a informação apresentada aqui (e nos textos seguintes) vaiparecer trivial, básico demais pro seu gosto. Mas, com certeza, para muitos outros pode serrealmente útil. O feedback de vocês é apreciado e pode nortear o desenvolvimento dos próximostextos. Vamos então ao que interessa. Nada mais justo que começar essa série de textos dando umanoção do protocolo HTTP, que é, de fato, a base sobre a qual a web se sustenta. Qualquer um quedeseje publicar qualquer tipo de recurso na web deve ter pelo menos algum conhecimento , aindaque básico, de HTTP. Principalmente hoje, com a popularização do AJAX, que consistebasicamente de requisições HTTP. HTTP é um protocolo, uma série de regras que definem comoum determinado diálogo deve ser conduzido. Basicamente o protocolo define que perguntas podemser 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, umrobô (googleboté um exemplo), um leitor de tela, um script, ou qualquer outro programa queconheça e saiba como seguir o protocolo. Quem dá as respostas é o servidor HTTP (ou servidorweb). Os dois servidores HTTP que dominam a quase totalidade do mercado hoje em dia são oApache, da Apache Foundation e o IIS, da microsoft. Nos últimos tempos olighthttpdvem ganhando alguma força, apoiado no crescente sucesso da linguagem de programaçãoRubye seuquase ubíquo companheiroRails.
Nota
: A não ser quando notado o contrário, todas asimplementações e códigos exibidos nesse texto e nos subseqüentes referentes a HTTP serãobaseados no servidor Apache.
O diálogo
E como é esse tal diálogo, regido pelo protocolo HTTP? Bom, existem muitas possibilidades deperguntas 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 muitoparecido com isso:
GET / HTTP/1.1Host: dominio.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)Gecko/20050915 Firefox/1.0.7Accept: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 usadopara “pegar” este recurso é o GET (que será explicado mais a frente) e que o protocolo usado é oHTTP versão 1.1. A partir da segunda linha começam os
request headers
. O primeiro deles informao host onde o recurso se encontra, na segunda o user agent se identifica (no caso acima é oFirefox 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 explorarmelhor os códigos de resposta nos próximos textos. Por agora, vamos ver como poderia ser umaresposta à requisição acima, caso o recurso fosse encontrado pelo servidor:
HTTP/1.x 200 OKDate: Mon, 12 Dec 2005 04:15:03 GMTServer: Apache/1.3.33 (Unix) DAV/1.0.3 mod_fastcgi/2.4.2 mod_gzip/1.3.26.1aPHP/4.3.10 mod_ssl/2.8.22 OpenSSL/0.9.7eContent-Type: text/html; charset=UTF-8
 
Com isso o servidor diz ao cliente que a requisição teve sucesso e o recurso foi encontrado (200OK), informa a data e hora, se identifica e mostra que tipo de documento está sendo enviado e qualo 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 documentoHTML. Como já disse acima, existem inúmeras possibilidades para as perguntas e respostas em umdiálogo HTTP. Esse texto foi apenas uma introdução ao protocolo. Você pode “bisbilhotar” osdiálogos HTTP que acontecem enquanto você navega usando a extensão Live HTTP Headers para oFirefox. Vá brincando com ela enquanto espera o próximo texto: Códigos de resposta e seussignificados.
Protocolo HTTP: métodos de requisição 
O método de requisição é o primeiro dado enviado pelouser-agentao fazer uma requisição HTTPao 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 oprotocolo 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, porisso, ser, de longe, o método mais usado. O método GET tem duas propriedades importantes: deveser
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ãono servidor. Ou seja, nunca se deve usar o método GET para, por exemplo, atualizar um dado emum banco de dados.
Idempotente
quer dizer que múltiplas requisições ao mesmo recurso usando o método devem ter omesmo resultado que teria uma requisição apenas. A título de curiosidade, idempotente é apropriedade 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 quepossuem a propriedade de ser idempotentes. Claro que há exceções. Por exemplo, digamos que orecurso requisitado seja a home page de um blog, que mostra os posts e o número de comentáriossubmetidos em cada um. Se, ao mesmo tempo que você faz suas requisições GET um outro usuáriopostar um comentário ou mesmo o autor do blog postar um novo texto, o resultado da requisiçãoserá 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. Oresultado 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 usoposterior, 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 sobrecache), 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
querystring
na URL que aparecerá na barra de endereços do browser. Além disso, deve-se tomar cuidadocom formulários usando esse método porque, caso a quantidade de informação submetida sejagrande 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. Aespecificação oficial do método GETpode serlida (em inglês) napágina de definição dos métodos HTTP, no site doW3C.
Protocolo HTTP: códigos de resposta mais comuns e seus significados 
No texto anterior, “Introdução aoHTTP” vimos de uma maneira bem básica o que é o HTTP ecomo se dá um diálogo entre cliente e servidor. Se você não o leu, leia. Pode ir lá ler que euespero… Ok, vamos continuar. A requisição ilustrada no último texto era a seguinte:
GET / HTTP/1.1Host: dominio.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)Gecko/20050915 Firefox/1.0.7Accept: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 aocliente. Essa resposta contém um código de resposta, que consiste de um número e uma pequenadescrição padrão do código. São vários os códigos possíveis, mas por enquanto vamos dar umaolhada 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 umredirecionamento; 4XX, que informam erros acontecidos no cliente e 5XX, erros no servidor. Nãovou tratar de nenhum código 1XX nesse texto. Por dois motivos: eles não são muito comuns eporque, devo confessar, não os conheço muito bem a ponto de escrever sobre.
Nota
: Perceba queestamos assumindo uma requisição GET básica. A coisa nem sempre é tão simples e, dependendodo método, o significado e as ações que devem ser tomadas pelo cliente diante de alguns códigos deresposta podem ser um pouco diferentes. Requisições mais complexas serão cobertas em textosfuturos. 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 comeste código o servidor deve enviar, acompanhado de alguns headers, o conteúdo do recursorequisitado que pode ser, por exemplo, um documento HTML ou XML , uma imagem JPEG ouGIF, 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. Aoreceber um código 302, o cliente deve procurar pelo header “Location”, que deve informar a URIpara a qual o recurso está sendo redirecionado. Em acessos futuros, a URI original deve ser

Activity (0)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Jessica Marinho liked this
Lúcia Pires liked this
Ricardo Ferreira liked this
Alexandre Cunha liked this
washalex liked this
jeffersonlv liked this
anacca liked this

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->