Universidade Federal de Goiás

Goiânia, 25 de Setembro de 2013

Disciplina: Redes de Computadores 1

Tomando como referência o RFC 2616 (HTTP 1.1), responda às seguintes perguntas:

a) Explique o propósito de cada um dos métodos que podem ser usados em requisições
do HTTP 1.1. ​Resposta baseada na referência [1]
OPTIONS: é o método que representa um pedido de informações sobre as opções de
comunicação disponíveis nas solicitações/respostas.

GET: é um método de recuperação de informações,

HEAD: é idêntico ao GET, exceto que o servidor não deve retornar o corpo da mensagem e sim
a 'meta-informação' contida no HTTP, ou seja,

POST: O método HTTP POST normalmente é usado ao criar um recurso quando a URL do
recurso final não for conhecida. Ele não é protegido e não é inalterável;

PUT: método normalmente utilizado para atualizar recursos ou para criar uma nova entidade
em uma URL conhecida.;

DELETE: comando solicita que o servidor de origem exclua determinado recurso identificado.
Infelizmente o cliente tem garantia de que a operação foi efetuada, mesmo se o código de
status retornado do servidor de origem indica que a ação foi concluída com êxito;

TRACE: é utilizado como um controle remoto de verificação que volta a mensagem solicitada.
Ele permite ao cliente ver o que está sendo recebido na outra extremidade do pedido e utilizar
esses dados para testes de diagnóstico ou informação;

CONNECT: comando reservado para realização de conexão com servidores (podendo ser
proxy, tunnel, etc).

b) Considerando requisições HTTP, liste todos os possíveis campos de cabeçalho

definidos no RFC. Em sua opinião, quais são os mais comuns e seus respectivos
significados? ​Resposta baseada na referência [2]
1. Cache-Control
2. Connection - permite ao emissor da mensagem especificar opções que são
desejadas especificamente para a conexão atual e que não podem ser
comunicadas por proxies através de outras conexões;
3. Date - data e hora da mensagem;
4. Pragma
5. Trailer
6. Transfer-Encoding
7. Upgrade
8. Via
9. Warning
10. Accept - especifica certos tipos de mídia que são aceitos como resposta;
11. Accept-Charset
12. Accept-Encoding
13. Accept-Language
14. Authorization
15. Expect
16. From
17. Host - especifica o host de internet e o número da porta do recurso requerido;
18. If-Match
19. If-Modified-Since - é utilizado como verificação por um método da mensagem;
20. If-None-Match
21. If-Range
22. If-Unmodified-Since
23. Max-Forwards
24. Proxy-Authorization
25. Range - indica o intervalo de bytes do corpo da entidade;
26. Referer
27. TE
28. User-Agent - contém as informações do usuário agente que iniciou o request.
29. Accept-Ranges
30. Age - contém a estimativa do originador da mensagem do tempo desde a resposta
gerada no servidor de origem;
31. ETag
32. Location
33. Proxy-Authenticate
34. Retry-After
35. Server - contém informações sobre o software utilizado pelo servidor de origem
para processar o request;
36. Vary
37. WWW-Authenticate - contém o esquema e os parâmetros de autenticação
aplicáveis à URL indicada pelo request.
38. Allow
39. Content-Encoding
40. Content-Language
41. Content-Length
42. Content-Location
43. Content-MD5
44. Content-Range
45. Content-Type
46. Expires
47. Last-Modified
48. extension-header
c) Considerando mensagens de resposta HTTP, quais são os códigos de status mais
comuns e seus respectivos significados?
1. 200 OK - Padrão de resposta para solicitações HTTP sucesso.
2. 302 Encontrado - Este é um exemplo de boas práticas industriais contradizendo a
norma.
3. 304 Não modificado - Indica que o recurso não foi modificado desde o último pedido.
4. 401 Não autorizado - Especificamente para o uso quando a autenticação é possível,
mas não conseguiu ou ainda não foram fornecidos.
5. 404 Não encontrado - O recurso requisitado não foi encontrado, mas pode ser
disponibilizado novamente no futuro.

d) Descreva em detalhes o funcionamento de conexões persistentes no HTTP 1.1,

conforme definido no RFC 2616.​ ​Resposta baseada na referência [2], tópico 8.1.4

(Tomando como base que o aluno tenha conhecimento da definição de ‘conexões persistentes’
no HTTP 1.1)

Servidores geralmente têm algum valor de tempo limite para o qual eles deixarão uma conexão
ativa. Os servidores proxy podem alterar este para um valor mais alto, pois é provável que o
cliente estará fazendo mais conexões através do mesmo servidor. O uso de conexões
persistentes não exige um tamanho ou a existencia do limite de tempo para o cliente ou para o
servidor.

Quando um cliente ou servidor deseja finalizar a conexão ele deve emitir uma mensagem para
isto. Clientes e servidores devem ambos constantemente prestar atenção ‘um para o outro’ a
fim de responder a ele conforme o caso. Se um cliente ou servidor não detecta o outro lado
poderia causar uma drenagem de recursos desnecessários na rede.

Um cliente, servidor ou proxy pode fechar a conexão de transporte a qualquer momento. Por
exemplo, um cliente pode ter começado a enviar um novo pedido ao mesmo tempo que o
servidor decidiu fechar a conexão. Do ponto de vista do servidor, a conexão está sendo
fechada , enquanto ele estava inativo, mas do ponto de vista do cliente, uma solicitação está
em andamento.

Isto significa que os clientes, servidores e procuradores devem ser capazes de recuperar de
eventos assíncronas. Software cliente deve reabrir a conexão de transporte e retransmitir a
seqüência abortada de pedidos sem interação do usuário, desde que a sequência do pedido é
idempotente*. Os métodos não idempotentes não deve ser repetida automaticamente, embora
os agentes possam oferecer um operador humano a escolha de repetir o pedido(s).
Confirmação de software cliente com a compreensão semântica da aplicação pode substituir a
confirmação do usuário. A repetição automática não deve ser repetida se a segunda seqüência
de solicitações de falhar.

Os servidores devem sempre responder a pelo menos um pedido por conexão, se possível .
Servidores não devem fechar a conexão enquanto transmitem uma resposta, a menos que se
suspeita de uma rede ou cliente que perdeu conexão.

Os clientes que usam conexões persistentes devem limitar o número de conexões simultâneas
que eles mantenham a um determinado servidor. Um cliente de um único usuário não deve
manter mais de duas conexões com qualquer servidor ou proxy. A procuração deve usar até 2
conexões*N para outro servidor ou proxy, onde N é o número de usuários ativos
simultaneamente. Estas diretrizes são destinadas a melhorar os tempos de resposta HTTP e
evitar congestionamento.

*​idempotente: ​é a propriedade que algumas operações têm de poderem ser aplicadas várias
vezes sem que o valor do resultado se altere após a aplicação inicial.

Referências para o Exercício03:

[1] RFC 2616 - Internet Engineering Task Force:​ ​http://www.ietf.org/rfc/rfc2616.txt

[2] O protocolo Http - estruturas específicas das mensagens:

http://desenvolvedor.ivarejo.com.br/Blog/oprotocolohttp-estruturasespecificasdasmensagens