HTTP: métodos (idempotência), status (401×403, 301×302, 5xx), stateless, cookies

A ideia que organiza o assunto

O HTTP é um protocolo de requisição e resposta em que o cliente sempre fala primeiro e o servidor não guarda memória da conversa anterior. Essas duas frases não são detalhes de implementação: são a arquitetura, e delas decorre tudo o que a prova cobra.

Porque o servidor não guarda contexto, cada requisição precisa chegar autocontida, com o método, o endereço e os cabeçalhos que a tornam interpretável sozinha. É isso que permite pôr proxy, cache e balanceador no caminho e atender a mesma sequência de chamadas em instâncias diferentes — e é isso que obriga a inventar cookie, token e sessão do lado de fora do protocolo para simular a continuidade que ele deliberadamente não oferece. Repare na inversão que a banca explora: o cookie existe porque o HTTP é sem estado, não como prova de que ele tenha estado.

Porque a resposta é sempre estruturada da mesma maneira — linha de estado, cabeçalhos e, se houver, corpo —, o código de status é obrigatório e o corpo é opcional. E porque o código tem três dígitos com o primeiro carregando a família, a leitura correta de uma resposta começa antes de saber o código exato: 4xx é culpa do cliente, 5xx é culpa do servidor. Só essa distinção resolve uma fatia grande dos itens, porque dela decorre a única pergunta prática que importa — vale a pena repetir a requisição sem mudar nada?

A terceira ideia é a semântica do método. O verbo não é decoração: ele declara ao servidor e a todo intermediário se aquela requisição altera o recurso (seguro) e se repeti-la soma efeito (idempotente). É a combinação dessas duas propriedades que autoriza um proxy a fazer cache, um navegador a repetir uma requisição que falhou e uma biblioteca a implementar retentativa automática.

O método para julgar item, então: identifique o dígito, identifique o verbo, pergunte de quem é a responsabilidade. Quase nada aqui exige memória além dessas três perguntas e das tabelas que as respondem.

Como funciona

A requisição tem uma linha inicial com método, alvo e versão, seguida de cabeçalhos e de um corpo opcional. A resposta tem uma linha de estado com a versão, o código de três dígitos e uma frase de motivo, seguida de cabeçalhos e de corpo opcional. O código é estrutural — não existe resposta HTTP sem ele —, ao passo que o corpo falta em várias situações legítimas: no 204, no 304 e em qualquer resposta a um HEAD.

Os métodos, pelas duas propriedades que decidem item:

GET — recupera a representação do recurso. Seguro e idempotente.
HEAD — idêntico ao GET, mas o servidor não envia o corpo: devolve só a linha de estado e os cabeçalhos que acompanhariam o GET. Serve para consultar metainformação — tamanho, tipo de mídia, data de modificação, ETag — sem pagar a transferência.
POST — submete dados para processamento; tipicamente cria recurso subordinado. Nem seguro nem idempotente: dois POST iguais criam dois recursos.
PUT — substitui integralmente o recurso no endereço indicado. Não é seguro; é idempotente, porque a segunda substituição pelo mesmo conteúdo deixa o recurso no mesmo estado.
PATCH — modificação parcial. Não é seguro e não é idempotente em geral (depende de como o corpo foi escrito).
DELETE — remove o recurso. Não é seguro; é idempotente, porque o recurso continua ausente depois da segunda tentativa, ainda que a resposta mude de 204 para 404.
OPTIONS — consulta as opções de comunicação; base da verificação prévia do CORS. Seguro e idempotente.
TRACE — devolve a requisição recebida, para diagnóstico de intermediários. Seguro e idempotente, e comumente desabilitado por segurança.

Seguro quer dizer que o método não pretende alterar o estado do recurso; idempotente quer dizer que o efeito de N requisições idênticas é o mesmo de uma. Todo método seguro é idempotente, mas a recíproca é falsa — PUT e DELETE são a prova.

As cinco famílias de status, cada uma com uma responsabilidade:

1xx informativa — a requisição foi recebida e o processo continua. O 100 Continue e o 101 Switching Protocols, que é o que fecha o handshake do WebSocket.
2xx sucesso — 200 OK; 201 Created, que acompanha o cabeçalho Location com o endereço do recurso criado; 202 Accepted, para processamento assíncrono; 204 No Content, sucesso sem corpo.
3xx redirecionamento — 301 Moved Permanently, mudança definitiva, que o cliente pode memorizar e que transfere o valor do endereço antigo para o novo; 302 Found, mudança temporária, em que o endereço original continua sendo o bom; 304 Not Modified, resposta a uma requisição condicional, sem corpo, que autoriza o cliente a usar o que já tem em cache; 307 e 308, equivalentes ao 302 e ao 301 que preservam o método da requisição original.
4xx erro do cliente — 400 Bad Request; 401 Unauthorized; 403 Forbidden; 404 Not Found; 405 Method Not Allowed; 409 Conflict; 429 Too Many Requests.
5xx erro do servidor — 500 Internal Server Error; 502 Bad Gateway; 503 Service Unavailable, com Retry-After; 504 Gateway Timeout.

401 contra 403 é a distinção mais cobrada da família 4xx. O 401 diz não sei quem você é: falta autenticação, ou a credencial apresentada não vale, e a resposta traz o cabeçalho WWW-Authenticate convidando o cliente a se autenticar. O 403 diz sei quem você é e não é o bastante: a autenticação foi aceita, mas aquela identidade não tem permissão para o recurso, e reapresentar a mesma credencial não muda nada. Em uma frase: 401 é autenticação, 403 é autorização.

429 Too Many Requests é a resposta ao excesso de requisições no intervalo — situação típica de força bruta, varredura e negação de serviço na camada de aplicação. A contramedida correspondente é a limitação de taxa, que inclui retardar deliberadamente a resposta para reduzir a taxa útil do atacante e encarecer cada tentativa.

Ausência de estado, na prática. O protocolo não guarda sessão, e o estado é reintroduzido por cima dele: cookie gravado no cliente e devolvido a cada requisição, token em cabeçalho de autorização, identificador de sessão que o servidor usa para buscar o contexto no seu próprio armazenamento. Nada disso altera a natureza do protocolo — apenas a contorna.

O que decide os itens

As famílias, pela responsabilidade e pela conduta:

família	de quem é a falha	repetir sem alterar nada resolve?
1xx	— informativa	—
2xx	— sucesso	—
3xx	— redirecionamento	segue-se o `Location`
4xx	do cliente	não — é preciso mudar a requisição
5xx	do servidor	pode — a falha é possivelmente transitória

Os pares que a banca opõe:

	significa	o que muda
401	não autenticado	falta credencial ou ela é inválida; vem com `WWW-Authenticate`
403	autenticado, sem permissão	reapresentar a credencial não adianta
301	mudança permanente	o cliente pode memorizar o novo endereço
302	mudança temporária	o endereço original continua válido
307 / 308	temporária / permanente	preservam o método; 301 e 302 podem virar GET
200	sucesso com corpo	—
204	sucesso sem corpo	—
404	recurso inexistente	culpa do cliente
500	falha no servidor	culpa do servidor
502 / 504	gateway	502 resposta inválida do servidor de origem; 504 tempo esgotado

Métodos, pelas duas propriedades:

método	seguro	idempotente
GET	sim	sim
HEAD	sim	sim
OPTIONS	sim	sim
TRACE	sim	sim
PUT	não	sim
DELETE	não	sim
PATCH	não	não (em geral)
POST	não	não

Regra de bolso: só o POST falha nas duas colunas; o PATCH falha na segunda; todo método seguro é idempotente e a recíproca é falsa.

Obrigatório × opcional na resposta:


código de status	sempre presente — é estrutural
corpo	opcional — ausente no 204, no 304 e em resposta a HEAD

Ausência de estado, nas duas direções:

o item diz…	veredito
o servidor não guarda contexto entre requisições	certo
cada requisição traz tudo o que é preciso para ser entendida	certo
o cookie existe porque o protocolo é sem estado	certo
o cookie torna o HTTP um protocolo com estado	errado
o servidor mantém sessão aberta entre duas chamadas	errado

Registro em log, em qualquer servidor web — IIS, Apache e NGINX gravam o mesmo núcleo de campos: endereço IP de origem, data e hora, método, recurso solicitado, código de status e tempo de resposta. É o conjunto que sustenta auditoria e resposta a incidente, e item que negue esse registro básico a um deles está errado.

Números que caem


porta do HTTP · do HTTPS	80 · 443
dígitos de um código de status	3; o primeiro define a família
famílias de status	5: 1xx, 2xx, 3xx, 4xx, 5xx
handshake do WebSocket	101 Switching Protocols
criado com sucesso, com `Location`	201
sucesso sem corpo	204
redirecionamento permanente · temporário	301 · 302
redirecionamentos que preservam o método	307 (temporário) · 308 (permanente)
conteúdo não modificado, resposta a requisição condicional	304
requisição malformada	400
não autenticado · sem permissão	401 · 403
recurso inexistente · método não permitido	404 · 405
conflito de recurso	409
excesso de requisições	429
erro interno do servidor	500
gateway inválido · serviço indisponível · tempo esgotado no gateway	502 · 503 · 504
métodos seguros	4: GET, HEAD, OPTIONS, TRACE
métodos idempotentes	6: os quatro seguros mais PUT e DELETE
método nem seguro nem idempotente	1: POST

Como a CEBRASPE derruba você aqui

A medição está fechada, e a primeira coisa que ela mostra é que o título promete mais do que a amostra cobra. São 8 itens explicados: 5 Certos e 3 Errados. Só 4 dos 8 são de HTTP — três de código de status (4xx contra 5xx, o 429 e a obrigatoriedade do código) e um único de método, o HEAD. Os outros quatro chegaram pelo enunciado do caderno, não pela matéria: log do IIS, git cherry-pick, realm do Tomcat e modo InPrivate do Edge. A tabela de idempotência dos métodos é, portanto, conteúdo de edital ainda não cobrado nesta amostra: está aqui porque é barata de guardar e decide item em qualquer caderno de API, não porque estes oito a tenham exigido.

Com três itens errados não há frequência a citar — os três fazem movimentos distintos, e é assim que estão descritos abaixo. O que é apenas conhecido do assunto vem rotulado como não medido.

Família de status trocada. “Usuários que recebem um código de status HTTP 4XX podem refazer a solicitação mesmo sem alterar nada e ter sucesso na próxima resposta” descreve corretamente a conduta diante de um 5xx e a pendura na família errada. O 4xx é erro do cliente: repetir a mesma requisição produz a mesma resposta. Sempre que um item associar uma conduta a uma família, faça a pergunta de quem é a culpa antes de aceitar.

Advérbio absoluto que está certo. “As requisições a um servidor Apache sempre retornam um código de status e, opcionalmente, um corpo de resposta” usa sempre e é verdadeiro, porque a obrigatoriedade do código é estrutural. É o caso que ensina a não marcar errado por reflexo: diante de sempre, procure a exceção concreta, e se não houver nenhuma, o advérbio é legítimo. Neste tópico há um par que se confunde — o código é sempre obrigatório, o corpo é sempre opcional.

Modo privativo com alcance esticado. O modo InPrivate do Edge “apaga os cookies, os arquivos baixados e os sites selecionados como favoritos durante uma sessão de navegação” — a frase começa certa e estende a regra a dois itens que sobrevivem ao fim da janela. O modo privativo descarta o rastro da navegação — histórico, cookies, dados de site e de formulário —, não os artefatos salvos: o arquivo baixado fica no disco e o favorito fica nos favoritos. Vale igualmente para o modo anônimo de qualquer navegador.

Ação real, componente errado. “Um realm no servidor Tomcat verifica a integridade de um arquivo ao comparar o seu resumo de mensagem com o do arquivo original” descreve verificação de checksum e a atribui ao repositório de usuários, senhas e papéis do Tomcat. A vizinhança é o que torna o item plausível — o realm de fato costuma guardar a senha como resumo de mensagem. Separe o objetivo: autenticar é provar identidade; comparar resumo de arquivo é conferir integridade.

Comando de versionamento trocado pelo vizinho — conhecido do assunto, não medido aqui. O único item de Git da amostra é Certo e descreve o git cherry-pick com precisão: aplica no ramo atual as alterações de commits já existentes e exige árvore de trabalho limpa. A troca segue previsível porque a família inteira é alvo — merge junta históricos, rebase reescreve a base do ramo, cherry-pick copia commits avulsos e revert cria um commit que desfaz outro —, e a descrição costuma vir correta com o nome do comando trocado. Fica registrada como expectativa, não como medição.

Erros clássicos

Confundir 401 com 403. 401 é autenticação — não sei quem você é, e a resposta traz WWW-Authenticate. 403 é autorização — sei quem você é e não basta. Reapresentar credencial resolve o primeiro e não resolve o segundo.

Confundir 301 com 302. 301 é permanente e o cliente pode memorizar o novo endereço; 302 é temporário e o original continua valendo. E nenhum dos dois garante preservar o método — quem garante são o 307 e o 308.

Achar que toda resposta tem corpo. 204, 304 e a resposta a um HEAD não têm. O que nunca falta é o código de status.

Achar que POST é idempotente. É o único método que não é seguro nem idempotente. Repetir um POST cria outro recurso.

Achar que DELETE não é idempotente porque a segunda resposta muda. A idempotência é do efeito sobre o recurso, não do código devolvido: depois da segunda tentativa o recurso continua ausente.

Achar que HEAD devolve um corpo reduzido. Não devolve corpo nenhum — devolve os mesmos cabeçalhos que o GET devolveria.

Achar que o cookie torna o HTTP um protocolo com estado. O protocolo continua sem estado; o cookie é o mecanismo externo que reintroduz continuidade justamente porque ele não a tem.

Tratar 429 como erro do servidor. É 4xx: quem excedeu o limite foi o cliente. A resposta costuma vir com Retry-After.

Confundir 403 com 404 em recurso protegido. Devolver 404 no lugar de 403 é decisão de projeto para não revelar a existência do recurso, e não equivalência entre os códigos.