1.
30-11-2010
Desenvolvimento de aplicações Web I
O PROTOCOLO HTTP
É 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)
1

2.
30-11-2010
HTTP e TCP/IP
O HTTP está no topo da stack do protocolo TCP/IP
Layer de Aplicação
HTTP
Layer de Transporte
TCP
Layer de Rede
IP
Layer de dados
Interfaces de Rede
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
2

3.
30-11-2010
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
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
Os segmentos são enviados
para o destino correcto
dentro dos datagramas IP
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
3

4.
30-11-2010
Ciclo básico Pedido/Resposta HTTP
Pedir um determinado recurso através
do seu URL
http://www.exemplo.com/cont1.hmtl
http://www.exemplo.com
HTTP REQUEST
HTTP RESPONSE
Cliente
HTTP
Servidor
HTTP
Recurso
cont1.html
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
4

5.
30-11-2010
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
5

6.
30-11-2010
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…
6

7.
30-11-2010
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/xwwwform-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
7

8.
30-11-2010
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?
8

9.
30-11-2010
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
9

10.
30-11-2010
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.
10

11.
30-11-2010
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_gzip
httpzip, 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
11

12.
30-11-2010
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
12

13.
30-11-2010
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
13

14.
30-11-2010
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 “query
strings” 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.
14

15.
30-11-2010
Enviar os dados via método GET
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>
Enviar os dados via método GET
O exemplo abaixo exemplifica quais as querys
strings e a maneira como são formadas
Enviar os dados via método GET
Os dados são enviados no próprio pedido
15

16.
30-11-2010
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.
16

17.
30-11-2010
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/)
17