terça-feira, 23 de setembro de 2008

Fazendo um HTTP GET via Telnet

Então, você fez seu sistema web bonitinho, verificou, lustrou, examinou, compilou, empacotou, e colocou (delicadamente!) o pacotinho dele no seu servidor de aplicação. Respirou fundo e iniciou o servidor. Nenhum erro no log. Tudo direitinho. Você então se levanta e diz - está funcionando!! Ótimo! Podemos ir pra casa!
Podemos mesmo?? Será que o sistema está no ar?? Se eu entrar na página inicial, será que ela vai abrir??
Muitas vezes, por mais estranho que pareça, uma ou outra coisa provoca que o sistema não esteja acessível ou visível para o usuário, mesmo estando "no ar"!! Ou o servidor de aplicação está na porta errada, ou a rede tem um redirecionamento faltando, a URL mudou, uma rota caiu, o DNS falhou, o Proxy não ficou bem configurado ou não está ativo... enfim, milhares de coisas podem acontecer para deixar seu sistema inalcançável. E, o mais interessante: como o desenvolvedor está sempre concentrado no sistema em si, grandes chances há que ele não se aperceba das dificuldades e fragilidades de ambiente e arquitetura de redes... o resultado pode ser catastrófico!!
Mas, para todos os grandes males... um pequeno (e singelo) remédio! Uma maneira fácil, simples, rápida e segura de testar se o seu sistema está acessível é fazer uma chamada GET de HTTP via telnet, e observar a resposta.
Funciona assim:

  • Abre-se uma conexão HTTP na porta correta usando o comando TELNET;
  • Faz-se uma chamada GET, digitando um comando muito simples, buscando uma página dentro do seu sistema, ou a raíz;
  • Analisa-se o resultado obtido.
O Telnet é usado apenas para abrir a conexão com o servidor onde está seu sistema, na porta onde ele atende. Assim, deve-se digitar:

telnet www.google.com.br 80

Para abrir uma conexão com o endereço "www.google.com.br". É preciso indicar a porta 80, pois a porta padrão do Telnet é a porta 23, mas queremos acessar a porta 80, que é a padrão do HTTP. A fórmula é sempre esta:

telnet [ENDEREÇO] [PORTA]

Uma vez com a conexão aberta, vamos fazer o comando GET:

GET / HTTP/1.1

O que isto significa?? Bom, vamos ver... a fórmula é:

GET [PASTA/ARQUIVO] HTTP/1.1

Isto significa que estamos fazendo um GET do arquivo que está em "/" (automaticamente, será o "/index.html" ou "/index.htm"), usando o protocolo HTTP, versão 1.1. Poderia ser qualquer outro arquivo, como "GET /index.php HTTP/1.1", ou "GET /isso/aquilo/aquilooutro/index.do HTTP/1.1", etc....
Esta requisição gera uma resposta HTTP, que é enviada em modo texto pelo telnet, e depois o servidor encerra a conexão (sim, as conexões HTTP são encerradas pelo servidor assim que termina a transferência; lembre-se disto!!). Vamos entender a resposta??

HTTP/1.1 302 Found
Location: http://www.google.com.br/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=e74d34b9a8ade746:TM=1222306186:LM=1222306186:S=9-4OKiByoC12DDCV; expires=Sat, 25-Sep-2010 01:29:46 GMT; path=/; domain=.google.com
Date: Thu, 25 Sep 2008 01:29:46 GMT
Server: gws
Content-Length: 222

[HTML DA RESPOSTA]

A resposta da conexão tem, essencialmente, 2 elementos importantes para nós: o cabeçalho (HTTP HEADER) e o texto de resposta. Qualquer página da internet, mesmo esta que você está vendo agora, vem inexoravelmente dentro de uma resposta HTTP, após seu devido cabeçalho. O cabeçalho (ou HEADER) é aquilo que instrui o seu navegador sobre como se comportar em relação a esta resposta (coisas como: o que exibir, se falhou, se funcionou, se pode fazer cache, se tem cookie, etc.). Vamos examinar algumas coisas principais do nosso cabeçalho:

  • HTTP/1.1 302 Found --> Aqui começa tudo! Indica que a URL, o endereço, foi encontrado com o código HTTP 302. Este código significa redirecionamento. Ou seja, a partir daqui, o seu navegador vai ser redirecionado para outro endereço. O servidor HTTP sempre responde com um código HTTP único, definido internacionalmente por especificação oficial do World Wide Web Consortium.
  • Location: http://www.google.com.br/ --> Indica de onde a resposta veio.
  • Cache-Control: private --> Indica que não se deve fazer cache. As informações são direcionadas a um único usuário.
  • Content-Type: text/html; charset=UTF-8 --> Indica que a resposta carrega um conteúdo texto, no formato HTML, codificado em padrão UNICODE UTF-8 (ou seja: pode usar acentos, cedilhas e todos os caracteres europeus). Isto é importante porque, se o conteúdo da resposta fosse um arquivo binário, como um ZIP ou um MP3, o navegador precisa lidar com eles de maneiras diferenciadas.
  • Set-Cookie: PREF=ID=e74d34b9a8ade746:TM=1222306186:LM=1222306186:S=9-4OKiByoC12DDCV; expires=Sat, 25-Sep-2010 01:29:46 GMT; path=/; domain=.google.com --> Pois é... como você viu, a google já coloca um cookiezinho na sua máquina... além deste valor estranho, o cookie tem uma data de expiração (sábado, 25/10/2010, daqui a 2 anos e 1 dia!!) e sabe o domínio de quem o criou (google.com).
  • Server: gws --> o nome do servidor que te respondeu (bom para saber o que o concorrente usa!!).
  • Content-Length: 222 --> O tamanho do corpo da resposta.

Estes são apenas alguns campos. Uma lista completa de todos os campos e suas definições encontra-se aqui. Vale lembrar que todo campo do cabeçalho sempre tem um nome, seguido do caracter ":" e o valor. Cuidado: estes campos são sensíveis a caixa (diferenciam minúsculas de maiúsculas).

Se quiser mergulhar a fundo na especificação do HTTP 1.1, acesse aqui.
Lembre-se: qualquer URL pode ser acessada por um GET via Telnet. Na verdade, o Telnet pode ser usado ainda para URLs de POST de HTTP, embora seja bem mais incômodo de fazer. O Telnet também pode se comunicar com seu servidor de e-mail, e é possível, via Telnet, enviar um e-mail para qualquer endereço de destinatário (e melhor: via telnet, o servidor não valida seu e-mail e você pode informar o endereço de remetente que desejar!!). Embora não seja complicado, isto tem sido cada vez menos utilizado, porque o permitir expõe o administrador da rede e o serviço de e-mail a riscos de segurança desnecessários.


  • Conclusão

Uma simples requisição via telnet lhe oferece um meio fácil e seguro de não só validar a disponibilidade de sua página ou sistema, como também extrair mais algumas informações inerentes a ela, ratificando a validação.

6 comentários:

Rety disse...

Muito bom! Nem sabia o que era o 302... haha muito obrigada!

O Pajé disse...

Disponha, Rety!! A alegria do Pajé é poder ajudar sempre!!

Anônimo disse...

Habilitei o telnet (prompt) no windows 7, mas quando eu digito telnet www.google.com 80 (ou outro servidor) dá uma mensagem rápida e apaga (aparentemente é aquela mensagem conectando ...), depois a tela fica preta e nada que eu digite aparece na tela? tem alguma dica. Queria mostrar em sala

O Pajé disse...

Olá Camarada (desculpe, vc não deixou o seu nome...),

Pode ser que o Windows 7 não esteja com o telnet funcionando configurado para funcionar propriamente com um acesso como este, ou seja, um acesso onde apenas se abre a conexão, sem receber o pedido de login. Testei no Debian e consegui proceder normalmente, veja:

paje@maquina:~$ telnet www.google.com 80
Trying 64.233.163.104...
Connected to www.l.google.com.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.1 302 Found
Location: http://www.google.com.br/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=c828845416419fb6:TM=1271466117:LM=1271466117:S=xWBi4aTDqXGboVMI; expires=Mon, 16-Apr-2012 01:01:57 GMT; path=/; domain=.google.com
Set-Cookie: NID=33=rLLQbMPjTqBPKgAPbtfIs4AvjR4umT7D9zd4Qj_nev7qqyHdsqb9gq9DkDRzljiLAFMtdvCPcHfu6TFzdtZAcxCciOwt4s9gxsD96Ya1myHU93tJiTIHJZs0zbCoUdZy; expires=Sun, 17-Oct-2010 01:01:57 GMT; path=/; domain=.google.com; HttpOnly
Date: Sat, 17 Apr 2010 01:01:57 GMT
Server: gws
Content-Length: 222

[HTML][HEAD][meta http-equiv="content-type" content="text/html;charset=utf-8"]
[TITLE]302 Moved[/TITLE][/HEAD][BODY]
[H1]302 Moved[/H1]
The document has moved
[A HREF="http://www.google.com.br/"]here[/A].
[/BODY][/HTML]

(substituí as tags do HTML por "[" e "]", para evitar a formatação automática)

Minha solução: para mostrar isto em aula, se não rodar no Windows 7, use o Ubuntu ou outra distro que roda do CD/DVD sem precisar instalar. Assim, a máquina fica intacta e você poderá fazer a demostração tranqüilamente. Boa sorte!!

Taf disse...

Olá!

Você sabe me dizer qual o problema quando faz uma requisição via POST e retorna o código de direcionamento(302) mesmo quando o direcionamento não esta "configurado"?

O Pajé disse...

Fala Rapaz!!

Eu preciso de mais detalhes... qual o erro que acontece?? Lembre-se de que o redirecionamento não implica validação do link ao qual a requisição vai ser redirecionada. Então, é possível que o redirecionamento seja feito e o link alvo do mesmo tenha caído, ou o servidor esteja mal configurado.