Blog do Urubatan
msgbartop
Desenvolvedor, Palestrante, Escritor, Nerd Assumido e Pai do Marcus :D
msgbarbottom

18 May 10 HTTP e URL – Dois ilustres pouco conhecidos

Este post foi extraido de uma apostila de um curso que ministrei em 2007, eu queria passar este texto para um colega novo do trabalho e não tinha o texto disponível, então resolvi publicar isto aqui no blog que vai ser útil para mim e pode ajudar mais alguem também :D


Para que seja possível acessar qualquer página na internet, alem de outros recursos, como FTP, SSH e diversos outros serviços, foi definido um padrão de endereçamento chamado URL (Uniform Resource Locator), que possui o seguinte formato:

PROTOCOLO://[USUARIO[:SENHA]@]ENDERECO_SERVIDOR/CAMINHO_NO_SERVIDOR?parametro=valor&outro_parametro=outro_valor#ancoraNaPagina

Por exemplo:

http://www.google.com/search?q=ruby+on+rails

onde:

  • http é o protocolo
  • www.google.com é o endereço do host
  • /search é o caminho dentro do servidor
  • q=ruby+on+rails é o parâmetro de nome “q” com o valor “ruby on rails”

Como uma URL não pode conter espaços os espaços são substituídos pelo sinal “+”, isto se chama codificar o parâmetro.

Como uma URL não aceita nenhum caractere com código ASCII maior que 127, qualquer caractere nesta categoria precisa ser codificado. Esta codificação consiste em substituir os caracteres por um “%” mais 2 dígitos numéricos representando o código ASCII em hexadecimal do caractere desejado, como na tabela a baixo:

Caractere Código Hexadecimal
$ 24
& 26
+ 2B
, 2C
/ 2F
: 3A
; 3B
= 3D
? 3F
@ 40
Espaço 20
22
< 3C
> 3E
# 23
% 25
{ 7B
} 7D
| 7C
\ 5C
^ 5E
~ 7E
[ 5B
] 5D
` 60

Alguns destes caracteres são aceitáveis em uma URL, mas em algumas situações precisam ser codificados, como por exemplo o # que pode ser utilizado no final de uma URL para indicar ao browser qual parte da página mostrar, quando não for utilizado para este fim, deve ser codificado para evitar confusões.

Cabeçalhos HTTP

Cabeçalhos HTTP são uma forma de passar parâmetros extras, além da URL do browser para o servidor. Normalmente, estes parâmetros são utilizados para informar ao servidor as capacidades do browser e preferências do usuário, mas podem também ser utilizados para trocar dados adicionais além dos informados pelo usuário (que podem ser passados pela URL).

Os cabeçalhos HTTP são enviados com o seguinte formato, logo depois da URL e antes da primeira linha em branco na requisição:

nome: valor

O valor dos cabeçalhos deve ser codificados utilizando a mesma tabela de conversão das URLs.

Exemplo de Requisião HTTP

O usuário digita no browser a URL: http://www.google.com/search?q=ruby+on+rails

O browser abre uma conexão TCP/IP na porta 80 (padrão) do servidor www.google.com e envia o seguinte texto:

GET http://www.google.com/search?q=ruby+rails HTTP/1.0
User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35  i686)
<Linha em branco no final>

O Servidor Responde:

HTTP/1.0 200 OK
Cache-Control: private
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=059bd3c506c56f82:TM=1189888548:LM=1189888548:S=hV0hCZi26b1SuRY7; expires=Mon, 14-Sep-2009 20:35:48 GMT; path=/; domain=.google.com
Server: gws
Date: Sat, 15 Sep 2007 20:35:48 GMT
Connection: Close

<html><head>
<Resto do HTML da página>

Explicando o que foi enviado:

  • GET http://www.google.com/search?q=ruby+rails HTTP/1.0
    • GET é o método sendo utilizado
    • http://www.google.com/search?q=ruby+rails é a URL solicitada no servidor
    • HTTP/1.0 é a versão do protocolo sendo utilizada
  • User-Agent: Mozilla/4.73 [en] (X11; U; Linux 2.0.35  i686)
    • User-Agent é um cabeçalho enviado que informa ao servidor qual browser esta fazendo a requisição
  • Linha em branco marcando o final da transmissão.

Explicando a resposta:

  • HTTP/1.0 200 OK
    • HTTP/1.0 é a versão do protocolo
    • 200 é o código da resposta que informa que o processamento esta OK
    • OK é um texto livre escrevendo o status, cada servidor pode responder com uma descrição diferente relativa ao código
  • Nas linhas seguintes, antes do espaço, tem diversos HEADERS que podem ser utilizados pelo browser
  • Após a linha em branco, há o conteúdo da URL solicitada

Métodos HTTP

GET

O método GET é utilizado para buscar o conteúdo de uma URL e o conteúdo retornado para a mesma URL deve ser sempre o mesmo. Isso facilita que o browser possa guardar páginas em cache por algum tempo para melhorar a experiência do usuário.

POST

O método POST é utilizado para enviar dados para o servidor. Esse método não possui a obrigatoriedade de ter sempre o mesmo resultado para os mesmos dados enviados.

PUT

O método PUT é utilizado para criar recursos no servidor. Ele possui a característica do método GET, de ter a mesma resposta para o mesmo conteúdo enviado.

DELETE

Este método é utilizado para remover recursos do servidor.

HEAD

O método HEAD serve para solicitar ao servidor apenas o cabeçalho do conteúdo com os headers, para que o cliente decida se precisa requisitar o conteúdo completo ou não.

Os métodos mais utilizados pela maioria das aplicações são o GET para buscar dados e o POST para enviar dados. Os métodos PUT e DELETE raramente são suportados por uma aplicação, mas são bastante úteis quando se deseja implementar Web Services seguindo o padrão REST. Alguns outros protocolos utilizam métodos adicionais e até definem alguns novos, como por exemplo o protocolo WebDav.

Códigos de resposta HTTP

Os códigos de resposta HTTP possuem 4 famílias básicas que serão apresentadas abaixo. Mais informações sobre estes códigos de resposta podem ser encontradas nesta URL: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

  • 1XX – Códigos de informação, muito pouco utilizados
  • 2XX – Sucesso: o código mais utilizado desta família é o 200 que significa OK
  • 3XX – Redirecionamento: os códigos mais utilizados desta família são: 301 redirecionamento permanente e 307 redirecionamento temporário
  • 4XX – Erro do cliente: o código mais conhecido desta família é o 404 que significa recurso não encontrado
  • 5XX – Erro do servidor: o código mais conhecido desta família é o 500 que significa erro interno do servidor.

Cabeçalhos comuns

Como o protocolo HTTP não mantém estado portanto, cada request é independente. Para solucionar este problema os cookies podem informar ao servidor quem é o cliente que está acessando o recurso.

Segue uma lista de alguns cabeçalhos bastante utilizados.

  • Location: utilizado junto com os códigos 301 e 307 informando o novo endereço do recurso
  • Content-Type: informa o tipo MIME do recurso retornado ou enviado ao servidor
  • Set-Cookie: grava um cookie no browser
  • Cookie: envia os cookies armazenados no servidor
  • Cache-Control: informa se o browser pode ou não armazenar o recurso em cache
  • Content-Length: informa o tamanho do conteúdo enviado ou da resposta
  • Last-Modified: informa ao cliente quando foi a ultima alteração do recurso solicitado
  • Accept: informa ao servidor quais são os tipos de recursos que o cliente sabe processar
  • Allow: informa ao cliente quais as ações disponíveis para um recurso especifico
  • Content-Encoding: informa ao cliente ou ao servidor qual a codificação que está sendo utilizada para o conteúdo enviado ou recebido
  • Host: informa ao servidor qual o nome do host utilizado no request. Bastante útil para possibilitar a configuração de hosts virtuais no mesmo endereço IP

Bom, acho que era isto, claro que isto não é tudo sobre formação de URLs e sobre o protocolo HTTP, mas já é um bom começo.

Tags: , , , ,