Tema: http
-
Como usar corretamente os códigos de status HTTP: a primeira bifurcação do cliente
Clientes, caches e agentes decidem só pelo código de status se repetem, recarregam ou desistem: 201/204 para sucesso com e sem corpo, 401 versus 403 para falta de autenticação versus falta de permissão, 409/412/428 para conflitos e pré-condições, 429 e 503 com Retry-After para «mais tarde». Um 200 com objeto de erro engana todos eles.
-
Respeitar o Retry-After como limite inferior
Agende novas tentativas a partir de qualquer uma das formas do Retry-After, preservando o prazo da tarefa e evitando requisições repetidas antes da hora.
-
Recuar como cliente: Retry-After, cabeçalhos RateLimit e orçamentos por host
Como um agente deve reagir a respostas 429 e 503 e a cabeçalhos consultivos de limite de taxa: respeitar o Retry-After à risca, senão recuar de forma exponencial com jitter, ler os campos RateLimit e RateLimit-Policy quando o servidor os envia para ajustar o ritmo antes do limite, manter um orçamento por host e por chave, e nunca repetir uma escrita não idempotente sem chave de idempotência.
-
Compressão de respostas: onde fazer e o que excluir
Comprima respostas de texto (HTML, JSON, Markdown) no proxy ou na aplicação, evite conteúdo já comprimido e streaming, mantenha os ETags coerentes entre codificações e defina Vary: Accept-Encoding.
-
Tracing distribuído em resumo: spans, IDs de pai e W3C Trace Context
Um trace é uma árvore de spans, cada um com ID do trace, ID próprio, ID do span pai, timestamps, atributos e status; o cabeçalho W3C traceparent leva o ID do trace, o ID do pai e um flag sampled entre processos, e um serviço que apenas repassa os dois cabeçalhos já mantém os traces unidos.
-
Páginas 404 personalizadas e soft 404: sirva a página de erro com o status de erro
Uma página 404 personalizada só ajuda os usuários se for servida com status 404; uma página de não encontrado servida com 200 é um soft 404, que os crawlers continuam a buscar e os buscadores excluem. O error_page do nginx pode reescrever o status (error_page 404 =200 ...), e é exatamente assim que soft 404 surgem por acidente; mantenha o status, torne a página útil e verifique com curl -I.
-
A Same-Origin Policy: o que é uma origem e o que ela isola
Uma origem é o conjunto formado por esquema, host e porta de uma URL. Scripts podem ler e modificar documentos, armazenamento e respostas da mesma origem; leituras entre origens são bloqueadas por padrão, enquanto escritas (como envio de formulários) e incorporações (como imagens e scripts) costumam ser permitidas. O CORS flexibiliza as leituras; as defesas contra CSRF continuam necessárias.
-
Usando fetch com timeouts e AbortController
A promise de fetch só é rejeitada em caso de falha de rede, não por status de erro HTTP, e não tem timeout próprio. Passe um AbortSignal combinado a partir de AbortSignal.timeout e do controller do chamador, verifique response.ok e distinga no catch entre TimeoutError, AbortError, erros de rede e erros HTTP.
-
Projetar operações idempotentes e repetições seguras
Uma operação é idempotente quando executá-la várias vezes tem o mesmo efeito que executá-la uma só vez; a RFC 9110 define isso para os métodos HTTP, e o cabeçalho Idempotency-Key estende a propriedade ao POST. Guarde a chave com impressão digital e resultado, sinalize conflitos com 409 e 422 e apague as chaves após um prazo documentado.
-
Server-sent events versus WebSockets
Server-sent events stream text events from server to client over plain HTTP with automatic reconnection and last-event IDs; WebSockets provide a bidirectional binary-capable channel with its own protocol. Choose SSE for one-way updates and WebSockets when the client must send frequently.
-
Chamando a API TypeSafe a partir de um agente: formato da requisição, erros, novas tentativas e fixação de versão
O contrato documentado de que um agente precisa para chamar o Jev sem camada de chat: POST /v1/systemone com chave Bearer, um estado, o nome do modelo e um mapa de perguntas tipadas; respostas com as mesmas chaves das perguntas mais um bloco usage; os status 401, 422, 429 e 529 com backoff exponencial; aliases que mudam e IDs versionados que não mudam; padrões dos SDKs para novas tentativas e a skill do agente para agentes de programação.
-
O cabeçalho Link e os tipos de relação de link
A RFC 8288 permite que qualquer resposta HTTP leve links tipados num cabeçalho Link: <destino>; rel="relação", com os parâmetros opcionais anchor, hreflang, type, title e media. Os nomes de relação vêm do registro da IANA (next, prev, canonical, alternate, describedby, preload) ou são URIs absolutas, no caso de extensões privadas. É assim que respostas que não são HTML apontam para recursos vizinhos e que o 103 Early Hints indica ao navegador o que buscar antecipadamente.
-
Noções básicas de Web Push: inscrições, chaves VAPID e o serviço de push
O navegador se inscreve no serviço de push do seu fabricante e entrega à página um endpoint e chaves; o servidor da aplicação envia por POST mensagens criptografadas para esse endpoint, com o cabeçalho TTL e um JWT VAPID (ES256, aud = origem do serviço de push, exp de no máximo 24 horas), cuja chave pública foi passada a PushManager.subscribe como applicationServerKey. Um 201 significa aceito, não entregue.
-
Sitemaps e endereços canônicos: um conteúdo, um endereço
Cada conteúdo deve ter exatamente um endereço canônico em HTTPS, declarado na própria página; versões gêmeas, como as em Markdown ou JSON, apontam para ele por meio do cabeçalho Link, parâmetros sem efeito sobre o conteúdo não geram novos endereços, e a sitemap lista apenas endereços canônicos com datas de alteração verdadeiras.
-
HEAD e OPTIONS: o que respondem e para que os clientes os usam
HEAD é um GET sem corpo: mesmo status e mesmos cabeçalhos (Content-Length e Vary podem ser omitidos), é cacheável e serve para verificar links, consultar tamanhos e checar atualidade. OPTIONS pergunta quais opções de comunicação um recurso ou o servidor inteiro (OPTIONS *) suporta, costuma ser respondido com Allow, não é cacheável e transporta os preflights de CORS com Access-Control-Request-Method.
-
Passo a passo de um encurtador de URLs: geração de chaves, status de redirecionamento e controles contra abuso
Um roteiro de projeto para um encurtador de URLs: chaves aleatórias em base62 com nova tentativa em caso de colisão, um caminho de redirecionamento que usa um cache e um armazenamento, 302 em vez de 301 quando os destinos precisam ser revogáveis e contabilizáveis, verificações de abuso na criação e uma lista do que não construir primeiro.
-
Reduzir cadeias de redirecionamento a um único salto aumenta a proporção de requisições de crawlers que terminam em 200 em sites grandes
Hipótese: em um site com dezenas de milhares de URLs e redirecionamentos acumulados, reescrever cada cadeia para que cada URL antiga responda com um único redirecionamento ao destino final aumenta de forma mensurável a proporção de requisições de crawlers de busca que chegam a uma página 200, dentro de um volume diário fixo de requisições, pois os crawlers gastam uma requisição em cada salto; propõe-se um teste de antes e depois com logs do servidor.
-
JSON Web Tokens: o que pode dar errado e as respostas da RFC 8725
JWTs são declarações assinadas, não segredos cifrados: valide o algoritmo contra uma lista de permitidos, verifique emissor, audiência e expiração, mantenha tempos de vida curtos, nunca aceite 'none' e lembre-se de que um token stateless não pode ser revogado sem uma lista no servidor.
-
Endpoints em lote e relatório de falhas parciais
Um endpoint em lote ou tem sucesso ou falha por inteiro, ou reporta o resultado de cada item; um único 200 não consegue expressar sucesso parcial. Por isso, escolha um comportamento por endpoint, identifique as falhas pela posição, limite o tamanho do lote e aplique autorização e limites de taxa por item.
-
Escolher códigos de status HTTP de forma deliberada
O código de status é a primeira coisa em que o cliente se baseia para decidir o que fazer: 200/201/204 para sucesso, 304 para sem alteração, 400/422 para entrada inválida, 401/403 para credenciais versus permissão, 404 para recurso inexistente, 409/412/428 para conflitos e pré-condições, 429/503 para tentar mais tarde.
Legível por máquina: JSON