Tecnologias Web 2010/11
Hypertext Transfer Protocol (HTTP)
Departamento de Ciência de Computadores
Faculdade de Ciências da Universidade do Porto
© Rui Prior
HTTP 1
World Wide Web
• Principais componentes da WWW
– Hypertext Markup Language (HTML)
– Hypertext Transfer Protocol (HTTP)
– Uniform Resource Identifiers (URIs)
• A arquitectura da WWW baseia-se no modelo
cliente/servidor
– Um cliente (web browser) comunica com um
servidor (web server) através do protocolo HTTP
para obter recursos identificados por URIs
• Mais especificamente, por URLs — Uniform Resource
Locators
HTTP 2
Anatomia de um URL
<scheme>://<user>:<password>@<host>:<port>/<url-path>;<params>?<query>#<fragment>
• scheme: define um método de acesso
• user e password: autenticação
• host: identificação do servidor — normalmente nome DNS
completo (FQDN) ou endereço IP
• port: porta TCP ou UDP (necessário se diferir da standard)
• url-path: caminho completo para o recurso no servidor
• params: parâmetros específicos do esquema, normalmente da
forma <parâmetro>=<valor>
• query: pergunta ou informação opcional passada ao servidor
• fragment: identifica uma localização particular dentro do
recurso
HTTP 3
URLs HTTP
http://<user>:<password>@<host>:<port>/<url-path>?<query>#<bookmark>
• port: porta (necessário se diferente da 80)
• url-path: sensível à maiusculização
• Note-se a ausência do campo params
• query: pergunta ou informação opcional passada ao
servidor através do método GET
• bookmark: identifica uma localização particular
dentro do documento HTML
– Útil para permitir o acesso directo a uma secção de um
documento grande
HTTP 4
HTTP
• Protocolo para transferência de recursos
– Pode transportar diferentes tipos de média (mime
types)
• Baseado em texto
– Embora o recurso transportado possa ser binário
•
•
•
•
Tipo pedido/resposta
Modelo cliente/servidor
Corre sobre TCP (porta 80)
Versão actual: 1.1
HTTP 5
HTTP: pedidos e respostas
• Sem intermediários
• Com intermediários
HTTP 6
Formato das mensagens HTTP
<start-line>
<message-headers>
<empty-line>
[<message-body>]
[<message-trailers>]
• start-line: identifica a natureza da mensagem (pedido
ou resposta), bem como informação específica de
mensagens desse tipo
• message-headers: cabeçalhos diversos, opcionais (excepto o Host: na ver. 1.1), do tipo <nome>: <valor>
• message-body: transporta um recurso (na norma é
designado entidade)
• message-trailers: quando se usa chunking, alguns
cabeçalhos dependentes do conteúdo podem aparecer
depois do recurso (e.g., Content-MD5: )
HTTP 7
Pedidos HTTP
<request-line>
<general-headers>
<request-headers>
<entity-headers>
<empty-line>
[<message-body>]
[<message-trailers>]
• request-line: <método> <URI> <versão>
• general-headers: cabeçalhos não específicos do tipo
de mensagem (pedido ou resposta) nem da entidade
• request-headers: cabeçalhos específicos do pedido
(e.g., condição, formatos, codificações, etc.)
• entity-headers: cabeçalhos específicos da entidade
(corpo da mensagem), se existir
HTTP 8
Pedidos HTTP
Método
URI do pedido
Versão do protocolo
HTTP 9
Métodos HTTP mais comuns
• GET: permite obter do servidor o recurso
identificado pelo URL
– É o método mais simples
– Utilizado quando se introduz um URL na barra de
endereços do navegador ou se clica num link
• POST: permite ao cliente enviar uma entidade
para o servidor para processamento
– Aconselhável para scripts CGI
• HEAD: idêntico ao GET, mas indica ao servidor
que não deve enviar o corpo da resposta
HTTP 10
Outros métodos HTTP
• OPTIONS: permite obter informação sobre
opções de comunicação para um dado URL ou
para o servidor em geral (URL = *)
• PUT: permite fazer o upload de uma entidade
para o servidor colocar no URL
• DELETE: pede ao servidor que apague o URL
• TRACE: pede ao servidor uma cópia do pedido
recebido, para fins de diagnóstico
• CONNECT: permite estabelecer um túnel
através de um intermediário
HTTP 11
Métodos seguros
• Métodos seguros são aqueles que é improvável terem
efeitos negativos no servidor
– Não alteram recursos no servidor
– GET, HEAD, OPTIONS e TRACE são métodos seguros
• Métodos considerados inseguros necessitam de ser
tratados com mais cuidado
– Alterações a recursos do servidor podem ser nefastas
– POST, PUT e DELETE são métodos inseguros
• A utilização do GET para invocar scripts que possam
alterar recursos no servidor é contrária à norma
– GET deixa de ser seguro…
HTTP 12
Métodos idempotentes
• Métodos idempotentes: múltiplas invocações para o
mesmo recurso têm o mesmo resultado que apenas uma
– Devolvem sempre a mesma resposta
– Efeitos colaterais de N invocações iguais aos de apenas uma
• Permitem caching de respostas
• Todos os métodos são idempotentes excepto o POST
– GET é idempotente, mas se invocar um script pode deixar de o
ser (uso contrário à norma HTTP)
– Aconselhável usar POST para invocar scripts
• Uma sequência de métodos idempotentes não é
necessariamente idempotente (e.g., GET + DELETE)
HTTP 13
Respostas HTTP
<status-line>
<general-headers>
<response-headers>
<entity-headers>
<empty-line>
[<message-body>]
[<message-trailers>]
• status-line: <versão> <código> <descrição>
• response-headers: cabeçalhos específicos da resposta
(informação adicional ao sumário contido na linha de
resposta)
HTTP 14
Respostas HTTP
Versão do protocolo, ≤ à do pedido
Código de estado
Descrição da razão
HTTP 15
Códigos de estado e descrições
• Cada pedido HTTP gera uma ou mais respostas
• Respostas contêm código de estado e
descrição textual
• Códigos da forma XYY (ver próximo slide)
• Descrições textuais dão indicação
humanamente compreensível
– Mensagens standard para cada código
– Podem ser substituídas por outras mais explícitas
HTTP 16
Formato dos códigos de estado
Código
Significado
Descrição
1yy
Informativa
Dá informação geral, não indicando sucesso ou
insucesso do pedido.
2yy
Sucesso
O método foi recebido, compreendido e aceite
pelo servidor.
O pedido não falhou completamente, mas é
necessária alguma acção adicional para que
possa completar-se com sucesso.
3yy
Redirecção
4yy
Erro do
Cliente
O pedido era inválido, continha erros de
sintaxe ou não pôde ser satisfeito por alguma
razão que o servidor crê ser erro do cliente.
5yy
Erro do
Servidor
O pedido era válido, mas o servidor não pôde
satisfazê-lo devido a um problema dele próprio.
HTTP 17
Exemplos de códigos
• 100 Continue
• 200 OK
• 301 Moved Permanently
• 307 Temporary Redirect
• 400 Bad Request
• 401 Unauthorized
• 403 Forbidden
• 404 Not Found
• 500 Internal Server Error
• 503 Service Unavailable
• 505 HTTP Version Not Supported
HTTP 18
Alguns cabeçalhos HTTP genéricos
• Cache-Control: controla caching nos vários
elementos (servidor, intermediários, cliente)
– E.g., Cache-Control: no-cache
• Connection: instruções para esta conexão
– E.g., Connection: close
• Date: data e hora de geração da mensagem
• Pragma: directivas específicas da
implementação
– E.g., Pragma: no-cache
• Via: indicação dos intermediários (e.g.,
proxies) atravessados pelo pedido ou resposta
HTTP 19
Alguns cabeçalhos HTTP de pedido
• Accept: permite ao cliente indicar que tipos de média pode
aceitar e respectivo factor de preferência
– E.g., Accept: text/html, text/*;q=0.6, */*;q=0.1
• Accept-Encoding: idem, para codificação (compressão)
• Accept-Language: idem, para língua
• Authorization: usado para apresentar credencias de
autenticação ao servidor
• Host: indica o nome DNS e, eventualmente, a porta, se diferente
de 80; é o único cabeçalho obrigatório (só HTTP 1.1)
• If-Modified-Since: condiciona pedido ao facto de a entidade ter
sido alterada desde o instante especificado
• Referer: URL do recurso de onde o URL do pedido corrente foi
obtido
• User-Agent: identificação do navegador
HTTP 20
Alguns cabeçalhos HTTP de resposta
• ETag: etiqueta para a entidade contida na resposta
• Location: indica novo URL em caso de
redireccionamento
• Proxy-Authenticate: é necessário o utilizador
autenticar-se no proxy
• Retry-After: permite indicar quando deve tentar de
novo um pedido (em caso de erro ou
redireccionamento)
• Server: identificação do servidor web
• WWW-Authenticate: indica, numa mensagem 401
Unauthorized, o método que o servidor pretende que o
utilizador use para se autenticar
HTTP 21
Alguns cabeçalhos HTTP de entidade
• Content-Encoding: indica a codificação (compressão)
da entidade
• Content-Language: língua
• Content-Length: tamanho da entidade, em bytes; útil
em conexões persistentes
• Content-MD5: permite verificar integridade da
entidade recebida
• Content-Type: tipo e subtipo MIME da entidade
• Expires: indicação para as caches de quando deve
expirar
• Last-Modified: indicação do instante da última
modificação à entidade
HTTP 22
Tipos de média
• Conceito herdado das extensões MIME ao
email
• Formato:
<tipo>/<subtipo>[;parâmetro1;parâmetro2;…;parâmetroN]
• Indicação do tipo de conteúdo da entidade no
cabeçalho "Content-Type:"
Content-Type: text/html
• Indicação dos tipos de conteúdo aceitáveis
por parte do cliente no cabeçalho "Accept:"
Accept: text/html, text/*;q=0.6, */*;q=0.1
HTTP 23
Codificação
• Dois níveis de codificação
– Codificação de conteúdo: permite comprimir a
entidade (gzip, compress, deflate)
• Cabeçalho "Content-Encoding:"
– Codificação de transferência: permite identificar o
fim da mensagem
• Cabeçalho "Transfer-Encoding:"
• Normalmente, o tamanho da entidade é indicado no
cabeçalho "Content-Length:"
• Quando não é possível saber esse tamanho a priori, (e.g.,
conteúdo dinâmico) é usada a codificação por pedaços
(chunked)
HTTP 24
Sem codificação de transferência
HTTP/1.1 200 OK
Date: Mon, 22 Mar 2004 11:15:03 GMT
Content-Type: text/html
Content-Length: 129
Expires: Sat, 27 Mar 2004 21:12:00 GMT
<html><body><p>The file you requested is 3,400 bytes long and was
last modified: Sat, 20 Mar 2004 21:12:00 GMT.</p></body></html>
HTTP 25
Codificação de transferência chunked
HTTP/1.1 200 OK
Date: Mon, 22 Mar 2004 11:15:03 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Trailer: Expires
29 Tamanho do pedaço em hexadecimal
<html><body><p>The file you requested is
5
3,400
23
bytes long and was last modified:
1d
Sat, 20 Mar 2004 21:12:00 GMT
13
.</p></body></html>
0
Expires: Sat, 27 Mar 2004 21:12:00 GMT
HTTP 26
Manutenção de estado: cookies
• O HTTP é um protocolo stateless
– As conxões persistentes na versão 1.1 não alteram
essa natureza
• Algumas aplicações requerem manutenção de
estado (e.g., carrinho de compras)
• Cookies permitem armazenar estado do lado
do cliente
– Servidor envia cabeçalho Set-Cookie: na resposta
– Cliente envia informação recebida em Set-Cookie
no cabeçalho Cookie: de pedidos subsequentes
HTTP 27
Manutenção de estado: cookies
Set-Cookie: <name>=<value> [; Path=<path>] [; Domain=<domain>] [; Expires=<date>] [; Secure]
Cookie: <name>=<value>
• Path: caminho abaixo do qual deve ser enviada a cookie
• Domain: nome ou domínio do servidor (e.g.,
server.example.com ou .example.com)
• Expires: data e hora a partir da qual perde validade e
deve ser eliminada*
– Com prazo de validade  cookie persistente
– Sem prazo de validade  cookie de sessão (apagada ao fechar o
browser)
• Secure: enviar apenas se o pedido for feito através de
ligação segura (https)
HTTP 28
Cookies: exemplo
• O cliente pede um documento e recebe na resposta:
Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT
• Quando o cliente pede um URL no caminho "/" nesse servidor envia:
Cookie: CUSTOMER=WILE_E_COYOTE
• O cliente pede um documento e recebe na resposta:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
• Quando o cliente pede um URL no caminho "/" nesse servidor envia:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
• O cliente recebe:
Set-Cookie: SHIPPING=FEDEX; path=/foo
• Quando o cliente pede um URL no caminho "/" nesse servidor envia:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
• Quando o cliente pede um URL no caminho "/foo" nesse servidor envia:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX
HTTP 29
Alguns potenciais problemas
• Transmissão de informação confidencial
– Alguém pode interceptar informação e usá-la indevidamente
• Armazenamento no cliente
– Quem tiver acesso à máquina pode ver as cookies armazenadas
• Armazenamento em caches
Cache-control:
Cache-control:
Cache-control:
Cache-control:
Cache-control:
no-cache="set-cookie"
private
must-revalidate
proxy-revalidate
max-age=0
Desactiva caching do cabeçalho Set-Cookie
Evita caching em caches públicas
Obriga a validação antes de enviar doc. em cache ao cliente
Idem, apenas em proxies
Pré-expiração (obriga a revalidar)
• Uso indesejável de cookies
– E.g., para monitorizar páginas visitadas (juntamente com cabeçalho
―Referer‖)
• Cookies de terceiros
– Um documento HTML pode ter embebidas imagens de outros
servidores; esses servidores podem enviar cookies mesmo sem o
utilizador os ter visitado conscientemente
HTTP 30
Backend em Base de Dados
• Quantidade de informação que se pode armazenar
numa cookie é limitada
– RFC-2109 recomenda um mínimo de 4kB
– Alguns browsers (antigos) só suportam 2kB
• Transferir um grande volume de dados em cada
pedido  overhead desnecessário
• Solução:
– Armazenar informação numa base de dados backend
– Cookie transporta apenas uma chave para aceder à BD
•
E.g., User ID
HTTP 31
Backend em Base de Dados: exemplo
cliente
ebay 8734
fich. de cookies
ebay 8734
amazon 1678
servidor
pedido http normal
resposta http normal
Set-cookie: 1678
pedido http normal
Cookie: 1678
uma semana
mais tarde:
ebay 8734
amazon 1678
resposta http normal
pedido http normal
Cookie: 1678
resposta http normal
Servidor Amazon
cria o ID 1678
para o utilizador cria
entrada
accção em
função da
acesso
cookie
acesso
base de
dados
back-end
accção em
função da
cookie
HTTP 32
Manutenção de Sessões
• É comum armazenar identificadores de sessão em cookies
• Nada impede o utilizador de continuar a utilizar a cookie mesmo
após esta ter expirado
– Ou outro utilizador que tenha espiolhado o pacote na rede...
• Duas soluções possíveis para evitar reutilização de
cookies expiradas:
– Se for utilizada uma BD de backend pode armazenar-se aí o
prazo de validade da sessão
– Caso contrário, pode enviar-se como parte do conteúdo da
cookie
• Prazo de validade
• Hash criptográfico sobre o prazo de validade que permita
verificar que o utilizador não está a mentir
HTTP 33
Autenticação HTTP
• Algumas páginas requerem autenticação/autorização
• Servidor responde com "401 Unauthorized" e
cabeçalho "WWW-Authenticate:" indicando o método
de autenticação desejado
• Browser deve pedir username/password ao cliente e
repetir o pedido ao servidor web, adicionando um
cabeçalho "Authorization:"
• Métodos de autenticação:
– Básico: <username>:<password> codificados em base64
• Inseguro, pois não é usada encriptação (excepto com HTTPS)
– Digest: hash MD5 de <username>:<password> é calculado
usando nonces de servidor e cliente
HTTP 34
Autenticação HTTP: Basic
• Pedido original (sem credenciais)
GET /private/index.html HTTP/1.0
Host: localhost
• Resposta do servidor
HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorised.</H1></BODY>
</HTML>
HTTP 35
Autenticação HTTP: Basic
• Novo pedido com credenciais
– username:password codificados em base64 (≈cleartext)
GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
• Resposta do servidor
HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476
...
• Cliente pode optar por enviar logo as credenciais em
pedidos subsequentes
HTTP 36
Autenticação HTTP: Digest
• Pedido original (sem credenciais)
GET /private/index.html HTTP/1.0
Host: localhost
• Resposta do servidor
HTTP/1.0 401 Unauthorized
Server: HTTPd/0.9
Date: Sun, 10 Apr 2005 20:26:47 GMT
WWW-Authenticate: Digest realm="[email protected]",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Content-Type: text/html
Content-Length: 311
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
...
HTTP 37
Autenticação HTTP: Digest
• Novo pedido com credenciais
– Uso de hashes evita circulação de credenciais em cleartext
GET /dir/index.html HTTP/1.0
Host: localhost
Authorization: Digest username="Mufasa",
realm="[email protected]",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="/dir/index.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
– realm, nonce e opaque dados pelo servidor
– nc (nonce count) = nº de pedidos (hex) com este nonce
HTTP 38
Autenticação HTTP: Digest
• Geração do valor de "response"
HA1 = MD5("Mufasa:[email protected]:Circle Of Life")
HA2 = MD5("GET:/dir/index.html")
# user:realm:password
# method:URI
response = MD5("939e7578ed9e3c518a452acee763bce9:\
dcd98b7102dd2f0e8b11d0f600bfb0c093:\
00000001:\
0a4f113b:\
auth:\
39aff3a2bab6126f332b942af96d3366")
= 6629fae49393a05397450978507c4ef1
#
#
#
#
#
#
HA1
nonce
nc
cnonce
qop
HA2
HTTP 39
Autenticação pela aplicação
• Muitas aplicações web implementam os
seus próprios métodos de autenticação
– Credenciais fornecidas através de
formulários
– Verificação de credenciais por consulta a
base de dados
– Manutenção de sessões usando cookies
• Potenciais falhas de segurança por
ignorância ou incúria do programador…
HTTP 40
Segurança e privacidade
• Métodos para garantir privacidade
– Cifragem do recurso por parte do servidor
• Informação nos cabeçalhos continua visível
– Uso de https
• http sobre SSL (Secure Sockets Layer) ou TLS
(Transport Layer Security)
• Mesmo com https pode haver fuga de
informação através do URI…
HTTP 41
Caching
• Pode existir em diferentes pontos
– Cliente
– Intermediário (e.g., proxy)
– Servidor (e.g., cache de páginas dinâmicas)
• 3 mecanismos básicos para controlo de caches
– Frescura
• Expiração temporizada de documentos em cache
– Validação
• É possível verificar se um documento expirado ainda é válido
(e.g., através de GET condicional)
– Invalidação
• Após um POST, PUT ou DELETE para um recurso em cache, este
torna-se inválido
HTTP 42
HTTP 1.0 e 1.1 — principais diferenças
• Suporte para servidores virtuais
– Cabeçalho Host: inexistente no 1.0, obrigatório no 1.1
• Selecção parcial de recursos
– Versão 1.1 permite transferir apenas parte de um recurso
• Melhor suporte para caches e proxies
– Permite melhorar o desempenho e ter maior controlo sobre o
que pode ou não ficar em cache e durante quanto tempo
• Negociação de conteúdos
– Permite seleccionar o melhor recurso ou versão de um
recurso quando existe mais que uma
• Maior segurança
– Versão 1.1 define métodos de autenticação e é mais segura no
cômputo geral do que a 1.0
HTTP 43
HTTP 1.0 e 1.1 — principais diferenças
• Conexões persistentes
– Na versão 1.0 o servidor fecha a conexão após enviar a
resposta ao único pedido
– Na versão 1.1 a conexão pode ser reutilizada para novos
pedidos
• Melhor desempenho, pois evita overhead de estabelecer nova
conexão TCP
• Necessária forma de identificar o fim de um recurso
transferido (cabeçalho Content-Length: ou chunking)
– Pode desactivar-se com cabeçalho Connection: Close
• Pipelining
– Possibilidade de enviar vários pedidos em sequência rápida
(respostas são dadas na mesma ordem)
– Evita perdas de tempo entre pedidos
HTTP 44
HTTP
• Para mais informação:
– Capítulos 79–84 do livro "The TCP/IP
Guide," C. M. Kozierok, No Starch Press
– Também disponível online:
http://www.tcpipguide.com/free/t_TCPIP
WorldWideWebWWWTheWebandtheHype
rtextTransferP.htm
– HTTP Cookie — Wikipedia
http://en.wikipedia.org/wiki/Http_cookies
HTTP 45