TECNOLOGIA GRATUITA: PROGRAMAÇÃO PARA AMBIENTES DE REDE TÓPICO: NOÇÕES DO PROTOCOLO HTTP

Transcrição

1 TECNOLOGIA GRATUITA: PROGRAMAÇÃO PARA AMBIENTES DE REDE TÓPICO: NOÇÕES DO PROTOCOLO HTTP /11 -

2 Conteúdo INTRODUÇÃO...3 DIAGRAMA DAS APLICAÇÕES...3 O PROTOCOLO HTTP...5 EXERCÍCIOS /11 -

3 INTRODUÇÃO A Internet pode ser analisada como antes e depois do advento do protocolo HTTP, ou Hyper Text Transfer Protocol. Os protocolos antecessores, WAIS e Gopher, apresentavam, já implementavam e exploravam, uma mesma ideia operacional: após o handshake inicial de uma conexão TCP: a aplicação servidora envia um conteúdo padrão para a aplicação cliente ou atende a requisição específica da aplicação cliente. Normalmente, o conteúdo inicial era texto puro com instruções de posicionamento em tela e opções numéricas. Devido às limitações das placas de vídeo da época haviam distorções na apresentação da tela de texto, pois a maioria não suportava o modo gráfico. No modo texto somente alguns tipos de fontes eram embarcados quando a placa era EGA ou VGA. Nenhum outro tipo de recurso era possível nas placas CGA. O protocolo de aplicação HTTP implementa a mesma raiz dos protocolos Gopher e WAIS. Contudo, a grande novidade e consagração da Internet foi o desenvolvimento e implementação das aplicações de visualização das páginas, agora capazes de explorar não só os novos recursos gráficos das placas de vídeo como também som e animações. Tais aplicações são hoje denominadas de Navegadores Web. DIAGRAMA DAS APLICAÇÕES A estrutura de um Navegador Web é complexa, mas bastante lógica e pode ser resumida em: Interpretador de HTML; Interpretador Javascript; Interligação para a máquina Java; Apresentador gráfico (vários modelos de imagens: gif, jpeg, png, etc); Engates para expansores/decodificadores de formatos (ou plugins) de vídeo e som, etc; A Figura 1 mostra um diagrama simplificado de um Navegador Web. O Módulo de Rede é a parte do software que troca informações com a aplicação servidora (Fig. 2) através da rede TCP/IP. Um cabeçalho, que antecede o conteúdo do arquivo enviado (o cabeçalho também faz parte do protocolo HTTP), é analisado pelo Interpretador HTML. Através de tal cabeçalho, o interpretador saberá qual módulo deverá ser chamado para tratar daquele conteúdo. - 3/11 -

4 Módulo de Rede Interpretador HTML Interpretador Javascript Interface Java Analisador Centralizador de recursos de vídeo Centralizador de recursos de Áudio Decoder Jpeg Decoder GIF Navegador Web plugins Fig. 1- Diagrama simplificado de um Navegador Web. Se o conteúdo for HTML então o interpretador lê, analisa linha por linha recebida, buscando as tags conhecidas e quais ações devem ser tomadas. O conteúdo pode exigir uma nova requisição (caso de imagens, sons ou mesmo outras referências). Enquanto o interpretador dispara a nova tarefa de download daquele novo conteúdo ele continua a interpretação. Se ao longo do conteúdo existir alguma referência a procedimentos Javascript então a máquina Javascript, presente no navegador, é acionada e a parte relacionada é transferida à ela. Se o conteúdo for Java então é acionado a máquina Java. As ações a serem tomadas são transferidas para o Analisador que, por sua vez, acionará o módulo visual ou multimídia correspondente (recursos de vídeo e/ou áudio). Alguns recursos requisitados pela página não são programados no Navegador, que necessitará de módulos externos ou auxiliares, denominados plugins. Os resultados das ações e decisões são apresentados em tela podendo ser gráfica ou simplesmente texto. Alguns exemplos de Navegadores Web: Internet Explorer, Mozilla FireFox, Seamonkey Navigator, Opera, Links, lynx etc. Os navegadores Links e Lynx não possuem ou apresentam recursos gráficos diretos, mas podem apresentá-los quando devidamente compilados. Eles, apenas, indicam a existência de imagens ou sons, mas não os interpreta. São excelentes ferramentas para decodificar páginas HTML em texto puro. A aplicação servidora é bem mais simples quando não exige interpretações de comandos ou requisições, conforme a Figura /11 -

5 Enquanto não há qualquer requisição, todos os elementos da aplicação servidora Web estão numa hibernação ou estado de espera. Assim que chegar alguma requisição pelo módulo de rede, ela é entregue ao Analisador de Requisição. A requisição é considerada como um apontador virtual, que será transferido para o Conversor de Referência Virtual para Real (CRVR). Módulo de Rede Analisador Requisição Seletor CGI PhP ASP Conversor Referência Virtual para Real Controle de Armazenamento Real Javascript Fig. 2- Diagrama Simplificado de uma Aplicação Servidora Web. O CRVR buscará, após a conversão, o conteúdo do arquivo requisitado e consultará o tipo de aplicação que foi configurada para tratar daquele conteúdo. Essa informação será transferida para a aplicação de navegação Web (aplicação cliente) através de instruções de cabeçalho. É isso que acontece com uma página com conteúdo estático. As requisições feitas pelo Navegador podem implicar no acionamento de interpretadores ou manipuladores secundários (exemplo: PhP, ASP ou uma CGI - Common Gateway Interface), que poderá modificar ou gerar o conteúdo conforme a requisição. Uma CGI é um procedimento especial. Através dela pode-se estabelecer enlaces com qualquer outro tipo de aplicação (exemplo: Banco de Dados, caixas postais de usuário, etc). Os detalhes sobre CGIs serão abordados em capítulo à parte. Exemplos de Aplicações Servidoras Web: IIS (Microsoft), Apache, Tomcat. Porém há uma grande lista de aplicações servidoras web disponíveis para várias plataformas. A URL apresenta várias delas. Vale a pena conhecer os tipos de licenças, os recursos embutidos, as plataformas que podem ser usadas, custos, etc. O PROTOCOLO HTTP Se você já teve curiosidade de ver o que são transferidos entre as aplicações WEB (Navegador e Aplicação Servidora Web) mas não percebeu o que acontece então a hora é essa! - 5/11 -

6 O protocolo HTTP opera segundo o paradigma cliente servidor. A aplicação cliente, o browser ou o navegador, envia uma requisição à aplicação servidora WEB. A resposta, normalmente um conteúdo HTML, é transferida para o browser, que a interpretará e a apresentará ao usuário. Sob o ponto de vista de conexão, pode-se resumir a operação conforme a Figura 3. Fig. 3-Modelo de conexão entre navegador (browser) e a aplicação servidora Web. Fig. 4- Visualização de um site local e do tipo do navegador. A Figura 4 é uma cópia de uma sessão HTTP. O cenário consiste de um navegador acessando uma aplicação servidora Web (Apache) em execução local e concorrente com o navegador. Ao investigar o tráfego entre as aplicações quando na requisição da página, foi obtido um conjunto de requisições e respostas conforme informado na Figura 3. As requisições - 6/11 -

7 são compostas por verbos e qualificadores enquanto as respostas por campos e conteúdos coerentes com o que foi requisitado. O efeito visual do navegador flui conforme as respostas são recebidas e apresentadas. A interpretação de cada linha de requisição e das respectivas respostas foram estudadas, lendo as RFCs do protocolo HTTP, disponíveis em: RFC-1945 ( RFC-2068 ( RFC-2616 ( e RFC-4229 ( As linhas são enumeradas conforme a origem (Navegador e Apache). O Navegador utilizado é um Mozilla Firefox, versão 3.0.3, conforme mostra a Figura 4. As linhas refletem o que acontece quando o usuário digitou a URL na caixa de acesso e pressionado a tecla enter. (Navegador - Req 1) 1) GET / HTTP/1.1(CR+LF) 2) Host: localhost(cr+lf) 3) User-Agent: Mozilla/5.0.(X11; U; Linux i686; en-us; rv: ).gecko/ firefox/3.0.3(cr+lf) 4) Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8(cr+lf) 5) Accept-Language: en-us,en;q=0.5(cr+lf) 6) Accept-Encoding: gzip,deflate(cr+lf) 7) Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7<CR+LF) 8) Keep-Alive: 300(CR+LF) 9) Connection: keep-alive(cr+lf) 10) (CR+LF) (WS - Resp 1) 11) HTTP/ OK(CR+LF) 12) Date: Tue, 03 Feb :47:03 GMT(CR+LF) 13) Server: Apache/2.2.6 (Mandriva Linux/PREFORK-8mdv2008.0)(CR+LF) 14) Last-Modified: Tue, 23 Sep :13:57 GMT(CR+LF) 15) ETag:."4ce40-1df2-53d5ab00"(CR+LF) 16) Accept-Ranges: bytes(cr+lf) 17) Content-Length: 7666(CR+LF) 18) Keep-Alive: timeout=5, max=100(cr+lf) 19) Connection: Keep-Alive(CR+LF) 20) Content-Type: text/html(cr+lf) <!DOCTYPE html PUBLIC."-//W3C//DTD HTML 4.01 Transitional//EN">... <img alt="guri.logo" src="gurilogo3.png"> Conteúdo HTML com 7666 bytes... (Navegador - Req 2) GET /GuriLogo3.png HTTP/1.1(CR+LF) Host: localhost(cr+lf) User-Agent: Mozilla/5.0.(X11; U; Linux i686; en-us; rv: ).gecko/ firefox/3.0.3(cr+lf) Accept: image/png,image/*;q=0.8,*/*;q=0.5(cr+lf) Accept-Language: en-us,en;q=0.5(cr+lf) - 7/11 -

8 Accept-Encoding: gzip,deflate(cr+lf) Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7<CR+LF) Keep-Alive(CR+LF) Referer: (CR+LF) (WS - Resp 2) HTTP/ OK(CR+LF) Date: Tue, 03 Feb :47:03 GMT(CR+LF) Server: Apache/2.2.6 (Mandriva Linux/PREFORK-8mdv2008.0)(CR+LF) Last-Modified: Fri, 16 Nov :27:02 GMT(CR+LF) ETag: "4ce33-2add-98f20d40"(CR+LF) Accept-Ranges: bytes(cr+lf) Content-Length: 10973(CR+LF) Keep-Alive: timeout=5, max=99(cr+lf) Connection: Keep-Alive(CR+LF) Content-Type: image/png(cr+lf) (CR+LF)... Conteúdo da referência GuriLogo3.png com bytes Analisemos o que aconteceu buscando elementos conhecidos. Considere CR+LF como os caracteres de controle Carriage-Return e Line-Feed. Tais caracetres são utilizados como separadores de atributos ou de definições. O usuário forneceu a localização O http representa o protocolo a ser utilizado. Se omitido o navegador insere automaticamente o protocolo padrão Web, que é o http. Muitos navegadores também são capazes de realizar conexões com outros protocolos (https, ftp, ftps, etc) além do http. Assim, a identificação do protocolo deve ser informada pelo usuário. Seria possível, ainda, especificar a porta de acesso. No caso, o usuário não a especificou, mas o navegador inseriu a porta padrão (porta 80). Caso fosse outra porta, o usuário deveria entrar com o seu número. Ou seja, o comando acima é equivalente a A dupla barra separa o protocolo de aplicação e o nome do host a conectar. No caso, o host é local, denominado localhost. A segunda barra a diante, /, define o nome virtual do conteúdo a ser requisitado. O navegador desconhece o tipo do conteúdo e o próprio conteúdo (tamanho) até que isso seja informado pela aplicação servidora. Considere a requisição 1 do Navegador (Navegador - Req 1) A linha 1 é uma tradução da requisição feita pelo usuário. O usuário informou /, logo a requisição é GET /. O complemento, na seqüência, corresponde a versão de protocolo que o navegador está apto a interpretar. No caso é HTTP versão 1.1. Se o usuário tivesse solicitado a requisição seria: GET /abacaxi.html HTTP/1.1 O GET reflete um dos métodos de requisição. Os outros possíveis métodos são: - 8/11 -

9 OPTIONS, HEAD, POST, PUT, DELETE, TRACE, CONNECT. A linha 2 informa o nome virtual do host a se conectar. É através do conteúdo de tal linha que elementos de rede conhecidos como PROXY HTTP, estabelecerão a conexão. Um proxy é um elemento intermediário entre o navegador e a aplicação servidora Web. Se o navegador foi configurado para utilizar um proxy então a conexão TCP/IP será feita com o proxy ao invés de uma conexão direta. Esta linha (Host: localhost) é importante nesse caso e outro caso. Algumas aplicações servidoras WEB implementam o conceito de portais virtuais (Virtual Hosts). Isso permite que um mesmo computador, executando uma única aplicação servidora WEB forneça conteúdos diferentes, que são identificados pelo valor do host. A linha 3 informa o tipo de navegador utilizado ou o User-Agent. Através dele a aplicação servidora web conhecerá o navegador e poderá impôr ou enviar conteúdos adequados para aquele tipo de navegador, com objetivo de melhor resultado visual. A finalidade de identificar o navegador é proporcionar a melhor visualização e não impedir o acesso! Infelizmente, alguns sítios sabotam a apresentação pela análise dessa informação. Analisemos o conteúdo do User-Agent informado: Mozilla/5.0.(X11; U; Linux i686; en-us; rv: ).gecko/ firefox/3.0.3 Trata-se de um Mozilla, versão 5, rodando sob ambiente gráfico X11, (U) plataforma Unix, com um SO Linux compilado para CPUs i686. O navegador tem a linguagem padrão no Inglês dos Estados Unidos e o interpretador HTML segue a revisão O modelo do navegador segue os padrões Gecko, da versão 16 do dia 24 de setembro (09) de 2008, e tem o nome de identificação Firefox, versão Conforme citado anteriormente, a informação do User-Agent pode ser modificada em vários navegadores. Mas ainda há outras informações que podem auxiliam na identificação do navegador. A linha 4 define a capacidade que o navegador tem para tratar o tipo esperado de conteúdo. Ou seja, o navegador espera que o conteúdo seja html, xhtml com ou sem xml, ou xml. Veja: text/html,application/xhtml+xml,application/xml; Os outros parâmetros especificam a o conjunto de bytes que podem ser utilizados. q=0.9,*/*;q=0.8 representa que preferências do tipo a receber. A preferência pode variar de 0 a 1 em ponto flutuante até 3 dígitos decimais. Um valor 0 significa que o navegador não tem capacidade qualitativa para apresentar os documentos com aquele tipo de conteúdo. Um valor igual a 1 significa que a qualidade de apresentação é perfeita. Seria como envie conteúdo somente com esse tipo. Tais valores atuam como pesos sobre os possíveis conteúdos. No caso, o navegador tem preferência 0.9 para conteúdos HTML, tem preferência de 0.8 para conteúdos puramente XML, mas também aceita, com qualidade pobre, conteúdos XHTML com XML. Tais informações são definidas na RFC2616. A linha 5, Accept-Language: en-us,en;q=0.5, especifica que o navegador tem preferencia por conteúdos em inglês (Estados Unidos), mas aceitará outras linguagens na mesma - 9/11 -

10 razão. È através dessa linha que as aplicações servidoras podem fornecer o conteúdo de uma página no idioma solicitado pelo navegador. A linha 6, Accept-Encoding: gzip,deflate, informa a aplicação servidora que o navegador poderá receber um conteúdo codificado (comprimido) usando um dos métodos: Lempel-Ziv (gzip) ou zlib (RFC1950). O accept-encoding também poderia ser compress ou identity. A linha 7, Accept-Charset: ISO ,utf-8;q=0.7,*;q=0.7, especifica que o navegador saberá tratar conteúdos em texto codificados no padrão ISO e utf-8. Outros padrões também são aceitáveis (*/*). A linha 8, Keep-Alive: 300, define que o navegador pode utilizar recursos de Keep- Alive. Ou seja, a sessão é mantida aberta mesmo sem trânsito de dados. Quando aceito, ocorre o fluxo de datagramas vazioo navegador de 300 em 300 segundos será enviado um datagrama TCP vazio esperando uma resposta sem conteúdo de 300 em 300 segundos. A linha 9, Connection: keep-alive, estabelece que a conexão atual segue o procedimento Keep-Alive apresentado acima. O campo Connection retrata o estado da atual conexão. A linha 10, linha com CR+LF e sem outros identificadores de campo, informa que a requisição acabou e que o navegador aguarda a resposta. A requisição recebida pela aplicação servidora, após processada, gerou a resposta identificada por (WS - Resp 1). Segue a análise da resposta: A linha 11, HTTP/ OK, indica que a aplicação servidora pode operar segundo as especificações do protocolo HTTP, versão 1.1. O número (200) e a palavra OK representam o status da operação. A URL trata dos vários estados de resposta. O número 200 indica que a requisição teve sucesso. A linha 12, Date: Tue, 03 Feb :47:03 GMT, informa o instante de atendimento daquela requisição. A linha 13, Server: Apache/2.2.6 (Mandriva Linux/PREFORK-8mdv2008.0), presta informações sobre a aplicação servidora. No caso, trata-se de um Apache, versão 2.2.6, rodando num sistema Mandriva Linux. O Apache usa o modelo PREFORK, da versão 2008 de um Linux Mandriva. A linha 14, Last-Modified: Tue, 23 Sep :13:57 GMT, representa a data de criação/atualização do conteúdo que será enviado. Tal informação é importante para saber quando a página foi modificada. Os navegadores com capacidade de caching (armazenamento temporário), verificam esse campo para saber se devem ou não atualizar a página existente em cache. Se ela não foi carregada previamente, o conteúdo será armazenado. Caso contrário, o navegador poderá descartar o restante e - 10/11 -

11 apresentar o conteúdo previamente armazenado. A linha 15, ETag:."4ce40-1df2-53d5ab00", identifica o recurso corrente ou a requisição corrente. A linha 16, Accept-Ranges: bytes, indica que a aplicação servidora Web aceitou a faixa de requisição para um recurso. A linha 17, Content-Length: 7666, espefica o número de bytes do que será enviado, ex: o número de bytes do conteúdo HTML de uma página, o número de bytes de uma imagem... A linha 18, Keep-Alive: timeout=5, max=100, confirma a possibilidade de operação em Keep-Alive, porém operando em 5 segundos e tentará conexão 100 vezes. Vencido os limites do critério a conexão será tida como encerrada. A linha 19, Connection: Keep-Alive, confirma a operação em Keep-Alive, conforme requisitado pelo Navegador. A linha 20, Content-Type: text/html, especifica que o conteúdo a ser enviado, a seguir, é um texto HTML. Isto indicará ao navegador que o conteúdo deve ser interpretado pelo módulo HTML. A partir do delimitador de final de cabeçalho, a aplicação servidora inicia o envio referente a página padrão. O conteúdo apresenta uma referência a uma imagem (<img alt="guri.logo" src="gurilogo3.png"> ), o que disparará uma nova requisição. EXERCÍCIOS 1) Baseando-se na análise acima, tente repetir a mesma análise para a requisição da imagem GuriLogo3.png. Busque as soluções dos exercícios abaixo nas RFCs. 2) Informe as finalidades dos seguintes cabeçalhos do protocolo HTTP: Content- Location e Cache-Control, If-Modified-Since e Pragma. 3) Descreva a finalidade dos Métodos de requisição: OPTIONS, HEAD, TRACE, LINK, UNLINK e CONNECT. 4) O que representa os códigos de estados: 204, 301, 400, 403 e 404? - 11/11 -