Dawi o protocolo-http

30-11-2010

1

O PROTOCOLO HTTP

Desenvolvimento de aplicações Web I

É a rede…

� É necessário conhecer o funcionamento do protocolo HTTP para podermos programar correctamente no Ambiente Web.� Se a rede não funcionar correctamente programadores/ utilizadores irão ter problemas.

� Mais tarde ou mais cedo vamos precisar/necessitar de utilizar: cache; autenticação, optimizar, entre outras…� Quando começamos a utilizar ferramentas como o AJAX conhecer o HTTP torna-se muito importante.

Introdução ao HTTP

� HTTP (Hyper Text Transfer Protocol)� É um layer de aplicação semelhante ao SMTP, POP, IMAP, FTP, etc.

� É um protocolo simples que define a forma como os clientes realizam pedidos de dados ao servidor e como este responde de volta.

� Tipicamente este serviço corre em cima do TCP/IP

� Existem 3 versões (0.9, 1.0, 1.1) das quais 2 ainda são utilizadas� RFC 1945 HTTP 1.0 (1996)� RFC 2616 HTTP 1.1 (1999)

30-11-2010

2

HTTP e TCP/IP

HTTP

TCP

IP

Interfaces de Rede

O HTTP está no topo da stack do protocolo TCP/IP

Layer de Aplicação

Layer de Transporte

Layer de Rede

Layer de dados

HTTP e TCP/IP

� O protocolo IP fornece pacotes que são encaminhados baseado no endereço IP de partida e chegada.

� O TCP fornece segmentos que são incorporados nos pacotes IP e adiciona o cabeçalho com informação do porto de destino e origem.� Os portos permitem ao TCP suportar protocolos múltiplos que conectam serviços em portas por omissão.� HTTP no porto 80� http com SSL(HTTPS) no porto 443� FTP no porto 21� SMTP no porto 25

30-11-2010

3

HTTP e TCP/IP

� O TCP fornece mecanismos que asseguram uma conexão robusta (byte pipe)� Handshake, números sequenciais, flags de controlo, checksum.

� O stream de dados é cortado em pedaços que são novamente juntos de uma forma organizada na outra ponta da ligação.

� Os segmentos de TCP que são enviados dentro de pacotes IP, levam esses pedaços de dados� Estes pedaços de dados são o conteúdo da mensagem de HTTP.

Exemplo de HTTP sobre TCP/IP

GET /index.html HTTP/1.1 <CRLF>Host: www.hostname.com Com…

A mensagem HTTP é cortada em

pedaços pequenos, o suficiente

para caberem num segmento de

TCP

Os segmentos são enviados

para o destino correcto

dentro dos datagramas IP

Estes pedaços movem-se

nos segmentos no interior

do TCP e são utilizados para

juntá-los de forma correcta

na outra ponta da ligação

Problemas … HTTP sobre TCP/IP

� HTTP/1.0 abre e fecha uma nova conexão TCP para cada operação. Uma vez que a maioria dos objectos Web são de pequenas dimensões esta prática implica uma maior fracção de pacotes sejam TCP.

� Acrescenta-se ainda ao ponto anterior os lentos mecanismos de controlo de congestionamento do TCP e deparamo-nos com operações HTTP/1.0 que utilizam o TCP de forma menos eficiente.

� HTTP 1.1 lida com este problemas utilizando ligações persistentes usando o Keep-Alive

30-11-2010

4

Ciclo básico Pedido/Resposta HTTP

Pedir um determinado recurso através do seu URLhttp://www.exemplo.com/cont1.hmtl

HTTP REQUEST

HTTP RESPONSE

http://www.exemplo.com

Recursocont1.html

Servidor HTTP

ClienteHTTP

HTTP ciclo de pedido/resposta exemplo 2

Tipos e utilização de Proxies

� Os proxys são intermediários HTTP� Actuam tanto como clientes como servidores

� A maioria dos proxys pode ser distinguido pelo local onde estão colocados e a forma como obtêm os dados� Explicit� Transparent� Intercepting� Reverse

� 3 principais razões para utilizações de proxys� Segurança� Performance� Filtragem de conteúdos

30-11-2010

5

Pedidos de HTTP

� Ambos os pedidos e respostas HTTP são tipos de mensagens da internet (RF 822), e partilham um formato geral:� Uma linha de início, seguida de CRLF (nova linha)� Linha de pedido para pedidos� Linha de informação para as respostas

� Zero ou mais mensagens de cabeçalho� Nomedocampo “:” [valor do campo] CRLF

� Uma linha vazia� 2 CRLF marcam o final dos cabeçalhos

� Um corpo da mensagem opcional

Exemplo de um pedido HTTP

Outro Pedido HTTP

30-11-2010

6

A linha de pedidos em detalhe

� Consiste em 3 principais partes� O método de pedido seguido de 1 espaço

� O HTTP 1.1 inclui os métodos: GET, POST, HEAD, TRACE, OPTIONS, PUT, DELETE e CONNECT

� Os mais utilizados são GET, POST e o HEAD

� O URI pedido seguido de um espaço� O endereço URL associado ao recurso

� A versão HTTP seguida por CRLF� 0.9, 1.0, 1.1

Pedido HTTP - Os métodos

� GET� É, de longe, o método mais utilizado� Retorna um recurso do servidor� Suporta a passagem de “query strings arguments”

� HEAD� Retorna apenas os cabeçalhos associados a um recurso mas não a entidade em si.

� Muito útil para o diagnóstico e análise do protocolo

� POST� Permite o envio de entidades de dados em vez de URL� Pode transmitir argumentos bastante maiores do que o GET� Os argumentos não são apresentados no URL.

Pedido HTTP - Mais métodos

� OPTIONS� Mostra os métodos disponíveis para utilizar com um determinado recurso ou servidor

� TRACE� Método de diagnóstico para avaliar o impacto de proxies ao longo da cadeia de pedidos.

� PUT, DELETE� Utilizados na publicação HTTP (WebDav)

� CONNECT� Uma extensão comum para correr outros protocolos sobre o HTTP

� Existem ainda mais métodos…

30-11-2010

7

Porque é importante?

� Quando estamos a programar para a Web poderá ser necessário formar pedidos HTTP em “bruto”� Por exemplo, através de JavaScript utilizando AJAX para formarmos um pedido HTTP utilizando o método GET ou POST para transmitirmos dados.

xmlhttp = ajaxhttp();

xmlhttp.open("POST", url, true);

xmlhttp.setRequestHeader("Content-Type", "application/xwww-

form-urlencoded");

xmlhttp.send("ret=" + escape(param));

� Nos formulários HTML ao atribuirmos um valor ao atributo action<form action=“GET|POST”> estamos a especificar o método HTTP para transmitir os dados.

Um olhar mais detalhado ao URI

� URI absolutos Vs caminhos absolutos� Proxies explícitos requerem URIs absolutos

� O cliente está directamente ligado ao proxy

� O protocolo e o nome do servidor necessitam ser resolvidos

� Pode ser necessário URL completos para os serviços Web

� Atenção com problemas como www vs no www

� Gramática para os caminho absolutos� É igual aos URIs absolutos menos a primeira parte http://hostname

� O “/” equivale à raiz dos documentos no servidor

� No HTTP 1.1 com “name-based virtual host” o protocolo já redirecciona para a document root apropriada

A resposta HTTP

� A resposta consiste também em 3 grandes partes� A versão HTTP seguida de um espaço

� O código de estado seguido de um espaço� 5 grupo de de 3 dígitos indicam o resultado da tentativa de satisfazer o pedido do cliente.

� 1xx são de informação

� 2xx são de sucesso

� 3xx são de recursos alternativos (redirects)

� 4xx indicam erros do cliente

� 5xx indicam erros no servidor

� A “frase resultado” seguida de CRLF

30-11-2010

8

Cabeçalho HTTP

� Os cabeçalhos aparecem normalmente em 4 tipos, alguns para pedidos outros para respostas alguns apara ambos� Cabeçalhos gerais

� Fornecem informação acerca das mensagens de pedido e resposta.

� Cabeçalhos de pedidos� Fornecem informação específica de mensagens de pedido.

� Cabeçalhos da resposta� Fornecem informação específica de mensagens de resposta.

� Cabeçalhos de entidades� Fornecem informação acerca das entidades de resposta e pedido

� São também possíveis cabeçalhos de extensão

Os cabeçalhos gerais (detalhado)

� Conexão - permite ao cliente e servidor gerir os estado da ligação� Connection: Keep-Alive (HTTP 1.0)� Connection: close (HTTP 1.1)

� Data – quando a mensagem foi criada� Date: Sat, 31-May-03 15:00:00 GMT

� Via – mostra os proxies que manipularam a mensagem� Via 1.1 www.mproxy.com (Squid/1.4)

� Cache-Control – está entre os headers mais complexos, permite enviar directivas de cache� Cache-Control:no-cache

Problemas com caches

� Após realizarmos um pedido, se o fizermos novamente o pedido do mesmo recurso, o browser não irá realizar uma nova ligação ao servidor (depende das opções seleccionadas no browser), mas sim utilizar os dados em cache. Isto pode causar problemas.� Exemplo: estarmos a ver conteúdo desactualizado� Exemplo: problemas com o AJAX

� Uma solução para cache desactualizadas é adicionar cabeçalhos de controlo de cache � É bom sabermos o que é cache e como utilizá-la correctamente� Quais os conteúdos que queremos colocar em cache?

30-11-2010

9

Cabeçalhos de pedido

� Host – o nome do anfitrião (e opcionalmente o porto) do servidor para o qual o pedido foi enviado.� Necessário para anfitriões virtuais baseados em nomes� Host: www.port80.com

� Referer – o endereço ou recurso a partir da qual o pedido foi gerado.� http://www.host.com/login.asp

� User-Agente – nome da aplicação que realizou o pedido (Browser).� User-Agent: Mozilla/4.0 (compatible; MSIE 6.0)

Cabeçalhos de pedido

� Accept e as suas variantes – informa o servidor das capacidades do cliente e as suas preferências.� Permite a negociação de conteúdos � Accept: image/gif, image/jpeg;q=0.5� Accept – variantes para a linguagem, codificação, charset

� If-Modified-Since e outras condicionais� Utilizado frequentemente pelos browsers para gerirem a cache� If-Modified-Since: Sat, 31-May-03 15:00:00 GMT

� Cookie – permite enviar as cookies para o servidor que as atribuiu� Cookie: id=13412; level=3

Utilizar os cabeçalhos de pedidos - Browser sniffing

� User-Agent: é normalmente utilizado para a detecção do browser que está a ser utilizado como cliente e desta forma apresentar diferentes conteúdos dependendo do browser utilizado.

� Uma abordagem melhor (para determinar qual é o cliente) é mesmo injectar um script no cliente de forma a fazer o profiling do cliente.

� No futuro, à medida que a diversidade de dispositivos com acesso a rede aumenta, o conceito de browser vai evoluir significativamente

30-11-2010

10

Utilizar os cabeçalhos de pedidos (Anti-leeching)

� Muitas vezes, algumas pessoas utilizam a nossa largura de banda ligando directamente (hotlink) aos nossos objectos (Gif, flash, etc.) sem retornar os objectos relacionados (ex. Publicidade).� Isto pode ser prejudicial se o nosso modelo de negócio estiver relacionado com publicidade à volta dos objectos “roubados”

� Uma forma muito simples de anti-leeching seria verificar o cabeçalho REFERER antes de enviar o objecto.

Utilizar os cabeçalhos de pedidos (Negociação de conteúdos)

� O Browser envia os cabeçalhos Accept indicando o tipo de conteúdos que este pode lidar

Utilizar os cabeçalhos de pedidos (Negociação de conteúdos)

� Um “q-rating” pode indicar qual a preferência que o Browser tem pelos dados solicitados

� A negociação de conteúdos permite-nos pedir qualquer coisa como “logo” e receber de volta a imagem apropriada (PNG, JPG, etc.) com base nas capacidades do dispositivo� Isto leva a conteúdos sem extensões o que a longo termo ajuda na manutenção

� A negociação dos conteúdos permite também que a linguagem seja automaticamente negociada.

30-11-2010

11

Utilizar os cabeçalhos de pedidos (Compressão HTTP)

� A compressão via HTTP é habilitada através da utilização de cabeçalhos Accept

� O browser envia os cabeçalhos indicando o tipo de compressão que aceita (gzip ou deflated). O servidor utilizando mod_gziphttpzip, etc. envia o conteúdo comprimido ou não.

� Apenas funciona com texto (html, css, JS) e atinge uma compressão de cerca de 70%

� Aumento do tempo de resposta, o que é mau para ligações de alta velocidade apesar de poupar largura de banda. Para ligações de baixa velocidade é claramente vantajoso

Exemplo de compressão HTTP

Considerações sobre compressão

� Considerações sobre TTFB (Time To First Byte) vs TTLB (Time To Last Byte) e redes

� Tempos necessários para descomprimir� Bugs…

� In Internet Explorer, … The bytes that remain to be decoded in the buffer may be small (8 bytes or less) and the data contained in the buffer decompresses to 0 bytes. … When shtml receives 0 bytes, it thinks that all the data is read and closes the data stream. As a result, the HTML page sometimes appears truncated. Typically, if it is for a referenced file such as a .js or a .css file type, the HTTP connection stops responding.

� A maioria destes problemas é resolvido através de aplicações comerciais instaladas no lado do servidor

30-11-2010

12

Cabeçalhos de resposta

� Server - o nome do servidor e versão� Server: Microsoft-IIS/5.0� Pode ser problemático por razões de segurança� Segurança ou obscuridade??

� Vary – Diz ao cliente e proxies de cache quais os cabeçalhos que foram utilizados para a negociação dos conteúdos� Vary: User-Agent, Accept

� Set-Cookie – é desta forma que o servidor coloca uma cookie no cliente� Set-Cookie: id=1234, path=/shop, expires=Sat, 31-May-03 15:00:00 GMT; secure

Cabeçalhos Entity

� Allow – lista os métodos de pedido que podem ser utilizados numa entidade� Allow: GET, HEAD, POST

� Location – indica uma localização alternativa ou nova da entidade� Utilizada com o código de resposta 3xx (redirects)� Location: http://www.ibm.com/us/

� Content-Encoding – especifica a codificação realizada no corpo da resposta� Corresponde ao cabeçalho de pedido Accept-Encoding� Content-Encoding: gzip

Mais cabeçalhos de entity

� Content-Length– o tamanho do corpo da entidade em bytes� Este valor diminui quando a compressão é aplicada

� Content-Lenght: 24000

� Content-Location– O URL real no caso da localização do recurso ser diferente do que o URL pedido� Muitas vezes utilizado para mostrar um index ou página por omissão

� Content-Location:http://www.foo.com/home.html

30-11-2010

13

Mais cabeçalhos de entity

� Content-Type – especifica o tipo de media do corpo da entidade (MIME)� Corresponde ao cabeçalho Accept� Content-Type: image/png

� Este é o cabeçalho mais importante para o browser. Este cabeçalho indica ao browser o tipo de dados que está a receber.� Server: file extension -> Mime type� Browser: Mime type -> acção (mostrar, descarregar)

� Sem o Mime Type o browser tem em conta apenas a extensão do ficheiro� Carregar um ficheiro do disco

Exemplo de utilização

� Ás vezes é necessário classificar os dados de saída do servidor com um MIME type apropriado

Mais cabeçalhos de entity: relacionado com cache

� Expires – atribui uma data a partir da qual a cache se torna obsoleta� Expires: Sat, 31-May-08 19:00:00 GMT

� Last-Modified – Data/hora em que a entidade foi modificada pela última vez � Last-Modified: Fri 30-May-07 09:00:00 GMT

� Etag – identificador único de um determinado recurso� Utilizado com pedidos condicionais para validar instâncias do recurso em cache� If-Match, If-None-Match

� Etag: adkskdashjgk07563AF

30-11-2010

14

A importância dos cabeçalhos

� Poderá ser necessário ir mais além do que o básico controlo de cache: � Prazos para Expirar os conteúdos

� E outro tipo de dicas para controlo de cache

� Em último caso, poderá ser necessário modificar as “querystrings” de forma a acabar com problemas de caches mal configuradas.

Enviar dados sobre o HTTP

� Os dados podem ser primariamente enviados de 2 formas:� Envio de uma “Query String” através de pedidos GET

� Envio dos dados através de pedidos POST

� Em ambos os casos, os dados são enviados de uma forma especial chamada x-www-form-urlencoded que irá substituir os espaços pelo carácter + os caracteres especiais pelo seu valor em hexadecimal e separa os argumentos individuais a serem enviados com o &.

Enviar os dados via método GET

� Neste caso podemos ver os dados submetidos no URL do pedido que estamos a realizar.

� Os dados enviados são apelidados de “Query String” e está depois do ponto de interrogação (?) No URL� Exemplo: http://www.utad.pt/index.php?aluno=al12556� Exemplo: http://www.utad.pt/index.php?anodematricula=2

� Este tipo de envio tem algumas desvantagens como:� A tecnologia está mais exposta - (reconhecimento visual)� É fácil encontrar os parâmetros � É mais difícil de manter a longo prazo� O tamanhos dos dados a enviar está condicionado pelo tamanho do URL

� Apesar disto os URLs baseados no método GET são portáveis – é possível fazer o bookmark da página, enviar por msn, etc.

30-11-2010

15


� Os dados enviados pelo método GET podem ser submetidos de 2 formas:� Escrita no próprio link

<a href=“http://www.utad.pt/index.php?aluno=al12556”>

� Como resultado de uma submissão:

<form action= href=http://www.utad.pt/index.php method=“get”>

<label>Aluno: <input type=“text” name=“aluno” /></label>

<input type=“submit” value=“Submit” />

</form>


� O exemplo abaixo exemplifica quais as querysstrings e a maneira como são formadas


� Os dados são enviados no próprio pedido

30-11-2010

16

Enviar os dados via método POST

� No caso do método POST podemos gerar os pedidos programando-os ou, de uma forma mais fácil, através de formulários

<form action=“http://www.fakesite.com/cgi-bin/submitquery. pl” method=“post”>Query: <input type=“text” name=“query” /><input type=“submit” value=“Submit” /></form>

� O pedido POST envia os dados no corpo da mensagem mas também de acordo com x-www-form-urlencoded . Sendo assim podemos ter um corpo de mensagem como:

Name=Al+Smith&Age=30&Sex=male

� Não existe tamanho limite para os dados a enviar, no entanto existem alguns problemas com os browsers, por exemplo o refresh da página.

Enviar os dados via método POST

� Um análise ao pedido mostra as diferenças entre os pedidos POST e GET

Quais as diferenças

� Os métodos GET e POST têm utilizações diferentes

� O GET é utilizado quando pedidos múltiplos podem ter a mesma resposta. O método POST deve ser utilizado quando é modificado o estado do servidor.

� Muitos programadores utilizam o GET para modificar o estado do servidor porque é mais fácil� Problemas – os estados do servidor podem ser alterados inadvertidamente por spiders, browsers, etc.

30-11-2010

17

Considerações acerca do HTTP

� O protocolo HTTP é stateless� Não existe memória de um pedido para o próximo

� Como podemos aceder a informação de pedidos anteriores?� Hidden filds nos formulários que são enviados para o cliente

� Dados nas URLs strings

� Cookies� Session cookies ou cookies persistentes

Adaptado de:

Credits to Prof. Thomas A. Powell (http://classes.pint.com/)

Documents

Dawi o protocolo-http