HTTP/HTTPS é um tema “carimbado” em provas de Informática porque mistura conceito, prática de navegação e segurança — terreno perfeito para pegadinhas como “HTTPS é outro protocolo” ou “HTTPS garante que o site é confiável”. Neste artigo, você vai entender o que cai de verdade: funcionamento, métodos, códigos, cabeçalhos, cookies/sessão e, principalmente, o que o HTTPS (TLS) garante e o que não garante.

1) O que é HTTP

HTTP (Hypertext Transfer Protocol) é um protocolo de aplicação usado para comunicação cliente-servidor na Web, no modelo requisição–resposta:

• o cliente (normalmente o navegador) envia uma requisição HTTP;
• o servidor responde com uma resposta HTTP (status + cabeçalhos + corpo).

Características que concursos cobram

• Camada: aplicação (no modelo TCP/IP, camada de aplicação; no OSI, aplicação).
• Orientado a recursos: URLs/URIs identificam recursos (página, API, imagem).
• Stateless (sem estado): por padrão, o servidor não “lembra” de requisições anteriores.
  O “estado” é simulado com cookies, tokens e sessões.

Pegadinha: “HTTP mantém sessão por padrão.” Não. HTTP é stateless; estado é implementado por mecanismos adicionais.

2) Estrutura básica de uma mensagem HTTP

Requisição (request)

Contém, em geral:

• linha inicial: método + caminho + versão (ex.: GET /login HTTP/1.1)
• cabeçalhos (headers): Host, User-Agent, Accept, Authorization, Cookie etc.
• corpo (body): em geral em POST/PUT/PATCH (formulários, JSON etc.)

Resposta (response)

Contém:

• linha inicial: versão + status code (ex.: HTTP/1.1 200 OK)
• cabeçalhos: Content-Type, Set-Cookie, Cache-Control etc.
• corpo: HTML, JSON, arquivo, etc.

3) Métodos HTTP mais cobrados

• GET: solicita um recurso (idealmente não altera estado). Pode ter parâmetros na URL.
• POST: envia dados para processamento (ex.: cadastro, login).
• PUT: substitui recurso por completo (muito em APIs).
• PATCH: altera parcialmente um recurso.
• DELETE: remove recurso.
• HEAD: como GET, mas sem corpo (útil para metadados).
• OPTIONS: consulta opções/capacidades (CORS/Preflight).

Propriedades “de prova”: safe e idempotent

• Safe (seguro): não deveria alterar estado no servidor (GET, HEAD, OPTIONS).
• Idempotent: repetir a mesma requisição gera o mesmo efeito (GET, PUT, DELETE, HEAD, OPTIONS).
  POST não é tipicamente idempotente.

Pegadinha: “POST é idempotente.” Em geral, não (pode criar múltiplos registros).

4) Códigos de status (status codes) essenciais

• 1xx: informacional
• 2xx: sucesso
  • 200 OK, 201 Created
• 3xx: redirecionamento
  • 301 Moved Permanently, 302 Found, 304 Not Modified
• 4xx: erro do cliente
  • 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
• 5xx: erro do servidor
  • 500 Internal Server Error, 503 Service Unavailable

Pegadinhas clássicas: 401 x 403

• 401 Unauthorized: falta autenticação (ou falha de autenticação).
• 403 Forbidden: autenticado (ou identificado), mas sem permissão.

5) Cookies, sessão e autenticação (como cai)

Como HTTP é stateless, sites implementam estado com:

• Cookie: pequeno dado armazenado no navegador e enviado ao servidor em requisições subsequentes (header Cookie).
  O servidor pode definir cookie com Set-Cookie.
• Sessão: estado mantido no servidor, associado a um identificador (muitas vezes guardado em cookie, como session_id).
• Token (ex.: Bearer/JWT): credencial enviada em header Authorization: Bearer ...

Pegadinha: cookie não é “necessariamente senha criptografada”. Cookie pode carregar ID de sessão ou preferências; segurança depende de flags (Secure, HttpOnly, SameSite) e do desenho do sistema.

6) Cache (muito cobrado em conjunto com HTTP)

HTTP possui mecanismos de cache via cabeçalhos como:

• Cache-Control
• Expires
• ETag e If-None-Match
• Last-Modified e If-Modified-Since

304 Not Modified indica que o cliente pode reutilizar o cache.

Pegadinha: cache melhora desempenho, mas pode gerar riscos se dados sensíveis forem cacheados indevidamente (por isso Cache-Control: no-store em páginas sensíveis).

7) O que é HTTPS (e o que ele realmente garante)

HTTPS é HTTP sobre TLS (antigo “SSL”), ou seja, não é um protocolo completamente diferente no sentido de “outro modelo de requisição”; é o mesmo HTTP trafegando por um canal criptografado e autenticado por TLS.

O que HTTPS/TLS provê (em geral)

• Confidencialidade: protege contra leitura por terceiros na rede.
• Integridade: detecta alteração do tráfego (evita adulteração “no caminho”).
• Autenticação do servidor: via certificado digital, permitindo ao cliente verificar que está falando com o servidor do domínio (cadeia de confiança).

Pegadinha 1: HTTPS não garante que o site é “honesto” ou “sem golpe”; garante que você está falando com o servidor daquele domínio (se o certificado for válido) e que o canal está protegido.

Pegadinha 2: HTTPS não impede phishing por si só. Um site fraudulento pode ter HTTPS válido (cadeado), desde que tenha um certificado para o domínio fraudulento que ele controla.

Como o TLS se conecta a simétrica e assimétrica (nível concurso)

• Criptografia assimétrica é usada no handshake para autenticação e negociação de segredos.
• Depois, a comunicação usa principalmente criptografia simétrica (mais rápida).

8) Portas padrão (cai muito)

• HTTP: porta 80 (TCP)
• HTTPS: porta 443 (TCP)

Observação: podem existir outras portas por configuração, mas “padrão de prova” é 80/443.

9) Vulnerabilidades e ataques relacionados (visão de concurso)

• Man-in-the-Middle (MitM): interceptação/alteração do tráfego; HTTPS reduz muito esse risco na rede, desde que não haja quebra de confiança (certificados falsos/instalados etc.).
• SSL stripping: tentativa de forçar conexão HTTP quando o usuário espera HTTPS (mitigável com HSTS).
• Cookies de sessão: risco de roubo (session hijacking) se não forem protegidos (Secure/HttpOnly/SameSite) e se houver XSS.

Pegadinha: HTTPS protege o transporte, mas não corrige vulnerabilidade de aplicação (ex.: SQL injection, XSS). Ele não “limpa” o site.

Questões autorais (estilo concurso) + gabarito + comentários

A) Certo/Errado (estilo CEBRASPE)

Q1. O HTTP é um protocolo stateless; mecanismos como cookies e sessões são utilizados para manter estado entre requisições.

Q2. O HTTPS garante que o conteúdo acessado é legítimo e que o site não será utilizado para golpes, pois o cadeado indica verificação completa da reputação do serviço.

Q3. No HTTPS, o uso de TLS provê confidencialidade e integridade do tráfego; além disso, costuma permitir autenticar o servidor por meio de certificados digitais.

Q4. O método HTTP GET é tipicamente usado para envio de dados que alteram o estado do servidor e, por isso, é considerado não idempotente.

Q5. O status code 401 indica falha ou ausência de autenticação, enquanto 403 indica falta de autorização para acesso ao recurso.

Gabarito (C/E)

• Q1: Certo
• Q2: Errado
• Q3: Certo
• Q4: Errado
• Q5: Certo

Comentários (C/E)

• Q1 (C): HTTP não mantém estado por padrão; cookies/sessões/tokens resolvem isso.
• Q2 (E): HTTPS protege o canal e autentica o servidor/domínio (se certificado válido). Não garante “idoneidade” do conteúdo. Pegadinha = exagero do cadeado.
• Q3 (C): TLS fornece confidencialidade + integridade e autenticação do servidor via certificado (cadeia de confiança).
• Q4 (E): GET é tipicamente safe e idempotent (não deveria alterar estado). Pegadinha = inverter propriedades.
• Q5 (C): 401 (autenticação) vs 403 (autorização) é comparação muito cobrada.

B) Múltipla escolha (A–E)

Q6. Assinale a alternativa correta sobre portas padrão:
A) HTTP usa TCP/443 e HTTPS usa TCP/80
B) HTTP usa TCP/25 e HTTPS usa TCP/110
C) HTTP usa TCP/80 e HTTPS usa TCP/443
D) HTTP usa UDP/80 e HTTPS usa UDP/443
E) HTTP e HTTPS usam exclusivamente UDP

Q7. Em uma aplicação web, após login bem-sucedido, o servidor envia ao navegador o cabeçalho Set-Cookie. Em requisições futuras ao mesmo domínio, o navegador tende a enviar automaticamente ao servidor:
A) Authorization
B) Cookie
C) ETag
D) Host
E) Cache-Control

Q8. Em relação a cache HTTP, o status 304 Not Modified indica que:
A) o servidor falhou e o cliente deve tentar novamente mais tarde
B) o recurso foi removido permanentemente
C) o cliente deve redirecionar para outro endereço
D) o cliente pode reutilizar a versão em cache, pois o recurso não foi modificado
E) a autenticação do cliente falhou

Q9. Assinale a alternativa que melhor descreve a relação entre HTTP e HTTPS:
A) HTTPS é um protocolo de camada de enlace que substitui HTTP na rede local
B) HTTPS é HTTP encapsulado em TLS, fornecendo canal criptografado e autenticação do servidor
C) HTTPS é HTTP com criptografia simétrica aplicada diretamente à URL, dispensando certificados
D) HTTPS elimina a necessidade de cookies, pois passa a manter estado automaticamente
E) HTTPS impede ataques de phishing, pois valida a reputação do site acessado

Gabarito (A–E)

• Q6: C
• Q7: B
• Q8: D
• Q9: B

Comentários (A–E)

• Q6 (C): padrão de prova: HTTP/80 e HTTPS/443 (TCP).
• Q7 (B): Set-Cookie é resposta; o cliente devolve em requisições futuras via header Cookie.
• Q8 (D): 304 indica “não modificado”, favorecendo cache/validação condicional (ETag/Last-Modified).
• Q9 (B): HTTPS = HTTP sobre TLS. Pegadinhas: dizer que elimina cookies/estado ou que impede phishing.

Checklist rápido (revisão pré-prova)

• HTTP é stateless; estado = cookies/sessões/tokens.
• HTTP 80 / HTTPS 443 (TCP).
• HTTPS (TLS) dá confidencialidade + integridade e autenticação do servidor (certificado).
• Cadeado não é “selo de honestidade”.
• 401 (autenticação) vs 403 (autorização).
• 304 Not Modified = use cache.