Nome: Darlan Ricardo Marangoni da Silva 0030481621011

Redes

1. Explique quais ações são requisitadas no HTTP REQUEST pelos seguintes métodos:

• OPTIONS

O Método OPTIONS é usado para descrever as opções de comunicação com o recurso alvo.

• GET

O Método GET é utilizado para solicitar uma representação de um recurso específico,

Requisições utilizando o Método GET devem retornar apenas dados.

• HEAD

O Método HEAD solicita uma resposta de forma identica ao processo que ocorre no tipo GET,
porém sem um corpo "body" contendo o recurso.

• POST

O Método POST é utilizado para submeter uma entidade a um recurso específico, às vezes
causando uma mudança no estado do recurso ou solicitando alterações do lado do servidor.

• PUT

O Método PUT substitui todas as atuais representações de seu recurso alvo pela carga de
dados da requisição.

• DELETE

O Método DELETE remove um recurso específico.

• TRACE

O Método TRACE executa uma chamada de loopback como teste durante o caminho de
conexão com o recurso alvo;

• CONNECT

O Método CONNECT estabelece um túnel para conexão com o servidor a partir do recurso
alvo;
2.Explique quais são as informações encontradas nos seguintes campos do cabeçalho
do HTTP REQUEST:

Request = Request-Line;

*(( general-header;

| request-header;

| entity-header ) CRLF);

CRLF

[ message-body ];

 Request line

A Request-Line começa com um método token, seguido pelo Request-Uri, a

HTTP-Version e termina com CRLF. Esses elementos são separados pelas letras
SP.

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

 General-header

Há poucos campos de cabeçalhos que tenham aplicabilidade geral para ambas

as mensagens de requisições e respostas, eles não se aplicam a que entidades
que estão sendo transferidas mas somente as mensagens.

general-header = Cache-Control ;
| Connection ;
| Date ;
| Pragma ;
| Trailer ;
| Transfer-Encoding ;
| Upgrade ;
| Via ;
| Warning ;

Os nomes dos campos de general-header podem ser estendidos de forma

confiável somente em combinação com uma alteração na versão do protocolo.
No entanto, campos de cabeçalho novos ou experimentais podem receber a
semântica de campos de general-header se todas as partes na comunicação os
reconhecerem como campos de general-header. Campos de cabeçalho não
reconhecidos são tratados como campos de entity-header.
 Request header field

Os request header field permitem que o cliente passe informações adicionais

sobre a solicitação e sobre o próprio cliente para o servidor. Esses campos
atuam como modificadores de solicitação, com semântica equivalente aos
parâmetros em uma chamada de método de linguagem de programação.

request-header = Accept ;
| Accept-Charset ;
| Accept-Encoding ;
| Accept-Language ;
| Authorization ;
| Expect ;
| From ;
| Host ;
| If-Match ;
| If-Modified-Since ;
| If-None-Match ;
| If-Range ;
| If-Unmodified-Since ;
| Max-Forwards ;
| Proxy-Authorization ;
| Range ;
| Referer ;
| TE ;
| User-Agent ;

Os nomes dos request header field podem ser estendidos de forma confiável
somente em combinação com uma alteração na versão do protocolo. No
entanto, campos de cabeçalho novos ou experimentais PODEM receber a
semântica dos request header field se todas as partes na comunicação
reconhecê-los como request header field. Campos de cabeçalho não
reconhecidos são tratados como entity header field.

 Entity header field

entity header field definem meta informações sobre o corpo da entidade ou, se
nenhum corpo estiver presente, sobre o recurso identificado pela solicitação.
Algumas dessas metainformações são OPCIONAIS; alguns podem ser
REQUERIDOS por partes desta especificação.

entity-header = Allow ;
| Content-Encoding ;
 | Content-Language ;
| Content-Length ;
| Content-Location ;
| Content-MD5 ;
| Content-Range ;
| Content-Type ;
| Expires ;
| Last-Modified ;
| extension-header
extension-header = message-header

O mecanismo de cabeçalho de extensão permite que entity header field

adicionais sejam definidos sem alterar o protocolo, mas esses campos não
podem ser considerados reconhecíveis pelo destinatário. Campos de cabeçalho
não reconhecidos devem ser ignorados pelo destinatário e devem ser
encaminhados por proxies transparentes.

 Message body

O message body (se houver) de uma mensagem HTTP é usado para transportar
o corpo da entidade associado à solicitação ou resposta. O message body difere
do entity header fild somente quando uma codificação de transferência foi
aplicada, conforme indicado pelo campo de cabeçalho Transferência-
Codificação.

message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>

A codificação de transferência DEVE ser usada para indicar quaisquer códigos

de transferência aplicados por um aplicativo para garantir a transferência
segura e adequada da mensagem. Transfer-Encoding é uma propriedade da
mensagem, não da entidade, e, portanto, pode ser adicionado ou removido por
qualquer aplicativo ao longo da cadeia de solicitação / resposta.

As regras para quando um message body é permitido em uma mensagem são

diferentes para solicitações e respostas.

A presença de um message-body em uma solicitação é sinalizada pela inclusão

de um campo de cabeçalho Content-Length ou Transfer-Encoding nos request
header field. Um message-body NÃO DEVE ser incluído em uma solicitação se a
especificação do método de solicitação não permitir o envio de um corpo de
entidade em solicitações. Um servidor deve ler e encaminhar um message body
em qualquer solicitação; se o método de solicitação não incluir a semântica
 definida para um corpo de entidade, então o corpo da mensagem DEVE ser
ignorado ao manipular a solicitação.

A mensagem depende do método de solicitação e do código de status da

resposta. Todas as respostas ao método de solicitação HEAD NÃO DEVEM
incluir um message body, mesmo que a presença de entity header field possa
levar alguém a acreditar que o faça.

3. Explique em quais condições são gerados os seguintes status code nas respostas HTTP:

•100 e 101: Indica que a solicitação foi recebida e que o servidor está pronto para dar
continuidade ao processo.

Os códigos mais comuns dessa classe são: 100 Continuar; 101 Mudando protocolos.

200, 201, 202, 203, 204, 205 e 206: Essa classe indica que a solicitação foi recebida, entendida
e que será processada com êxito pelo servidor. Os códigos mais comuns dessa classe são: 200
OK; 201 Criado; 202 Aceito; 203 não-autorizado; 204 Nenhum conteúdo; 205 Reset; 206
Conteúdo parcial; 207-Status Multi.

300, 301, 302, 303, 304, 305, 306 e 307: Indica que você será redirecionado a outra página.
Isso acontece, por exemplo, quando a URL que você pesquisou foi alterada, mas o
administrador do site te redireciona para a página atual. Os códigos mais comuns dessa classe
são: 300 Múltipla escolha; 301 Movido Permanentemente; 302 Encontrado; 304 Não
modificado; 305 Use Proxy; 307 Redirecionamento temporário

400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417: Esse
status indica que o servidor não conseguiu processar a solicitação porque o cliente a fez de
forma errada ou que não dependa dele, como por exemplo uma página excluída. Os códigos
mais comuns dessa classe são: 400 Requisição inválida; 401 Não autorizado; 402 Pagamento
necessário; 403 Proibido; 404 Não encontrado; 405 Método não permitido; 406 Não Aceitável;
407 Autenticação de proxy necessária; 408 Tempo de requisição esgotou; 409 Conflito.

500, 501, 502, 503, 504, e 505: Esse status indica que, por um erro do servidor, a sua
solicitação não pode ser atendida. Na maioria das vezes está relacionada a permissões dos
arquivos ou pastas de software. Os códigos mais comuns dessa classe são: 500 Erro interno do
servidor; 501 Não implementado; 502 Bad Gateway; 503 Serviço indisponível; 504 Gateway
Time-Out; 505 HTTP Version not supported.