Anúncios incomodam? Ir Sem anúncios Hoje

Construtor de Resposta HTTP Falso

DadosDesenvolvedorRede
ANUNCIADO Remover?
Sobrescrita opcional para o texto de razão após o código de status.

Cabeçalhos Personalizados

Ou adicione personalizado

Cabeçalhos Adicionados

Nenhum cabeçalho personalizado adicionado ainda. Cabeçalhos comuns (Content-Type, Content-Length, Date) são adicionados automaticamente com base nas opções acima.

ANUNCIADO Remover?

Guia

Construtor de Resposta HTTP Falso

Construtor de Resposta HTTP Falso

Construa uma mensagem de resposta HTTP estruturalmente correta em segundos. Escolha um código de status, escolha um tipo de corpo, adicione cabeçalhos e a ferramenta emite uma string pronta para colar com a linha de status, cabeçalhos e corpo separados por CRLF — ideal para testes, mocks, documentação de API e repetição de respostas contra clientes.

Como usar

  1. Escolha o Versão HTTP (padrão HTTP/1.1) e um código de status do seletor agrupado — por exemplo 200 OK, 404 Not Found, ou 503 Service Unavailable.
  2. (Opcional) Sobrescreva o texto de razão se necessário um texto não padrão após o código de status.
  3. Escolha um tipo do corpo (Texto simples, JSON, XML, HTML, Formulário ou Nenhum) e digite ou cole o corpo.
  4. Alternar conteúdo automático do Content-Type, conteúdo automático do Content-Lengthe, e Data para que os cabeçalhos correspondam à forma como seu servidor responderia.
  5. Adicione quaisquer cabeçalhos extras — escolha entre os comuns (Cache-Control, ETag, Set-Cookie, CORS, cabeçalhos de taxa de limite) ou digite um par nome/valor personalizado.
  6. Copie a resposta completa, copie apenas os cabeçalhos ou baixe como um .http arquivo para uso em clientes REST, fixtures ou ferramentas de repetição.

Características

  • Seletor agrupado de códigos de status – Códigos comuns de 1xx até 5xx organizados por classe, cada um com sua frase padrão de razão.
  • Seletor de tipo de corpo – Preenche automaticamente o Content-Type correspondente (application/json, text/html, application/xml, application/x-www-form-urlencoded, text/plain) para manter os cabeçalhos e o corpo sincronizados.
  • Conteúdo automático do Content-Length – Conta os bytes (não os caracteres) usando codificação UTF-8, correspondendo à forma como servidores reais calculam o valor.
  • Cabeçalho Date com IMF-fixdate – Gera um timestamp padrão (por exemplo Sun, 06 Nov 1994 08:49:37 GMT) para o momento atual.
  • Cabeçalhos comuns de resposta – Presets de um clique para Cache-Control, ETag, Expires, Last-Modified, Location, Server, Set-Cookie, Vary, WWW-Authenticate, Access-Control-Allow-Origin, X-RateLimit e X-Powered-By.
  • Cabeçalhos personalizados – Adicione qualquer par nome/valor, com pré-visualização em tempo real da resposta montada.
  • Duas visões de saída – Resposta completa (linha de status + cabeçalhos + linha em branco + corpo) e apenas cabeçalhos — copie qualquer uma delas ou baixe a resposta completa como response.http.
  • Terminadores de linha conformes ao padrão – Usa CRLF (\r\n) entre as linhas, o terminador de linha exigido pelo RFC 9112.
  • Atualizações em tempo real – Cada alteração recalcula a saída instantaneamente; não é necessário um botão de envio.
  • Executa totalmente no navegador – Nenhum dado sai da sua máquina e nenhum backend é envolvido.

Casos de uso comuns

  • Fixtures para testes unitários e de integração – Cole a saída em um fixture de string para requests-mock, nock, MSW, WireMock ou qualquer registrador HTTP.
  • Documentação de API – Mostre uma forma exata de resposta (com cabeçalhos) em exemplos OpenAPI ou documentação para desenvolvedores.
  • Depuração do cliente – Reproduza uma resposta rara do servidor (limitação de taxa, conteúdo parcial, redirecionamento) sem precisar executar um backend real.
  • Ensino de HTTP – Visualize o formato na rede de uma mensagem de resposta: linha de status, cabeçalhos, linha em branco, corpo.
  • Repetição manual – Pipa a resposta para nc -l ou um listener semelhante para testar como o cliente reage.

Perguntas frequentes

  1. Qual é a estrutura de uma mensagem de resposta HTTP/1.1?

    Uma resposta HTTP/1.1 consiste em uma linha de status, zero ou mais campos de cabeçalho, uma linha em branco e um corpo opcional. A linha de status é a versão HTTP, o código de status de três dígitos e uma frase de razão separados por espaços únicos. Cada linha termina com CRLF (retorno de carro + quebra de linha). A linha em branco após o último cabeçalho marca o início do corpo. Esta forma é definida no RFC 9112 (o sucessor do RFC 7230).

  2. O Content-Length mede realmente bytes ou caracteres?

    O Content-Length é o comprimento do corpo da mensagem em octetos (bytes), não em caracteres. Para texto ASCII os dois valores coincidem, mas para qualquer string UTF-8 contendo caracteres não-ASCII eles divergem — um emoji ou uma letra acentuada usa geralmente 2 a 4 bytes. Calcular o Content-Length com base no número de caracteres de uma string é uma das mais comuns falhas HTTP e causará clientes a truncarem o corpo ou a pendurarem esperando por bytes faltantes.

  3. Qual a diferença entre um redirecionamento 301 e um 302?

    Ambas as respostas incluem um cabeçalho Location apontando para uma nova URL, mas os significados são diferentes. Um 301 Moved Permanently informa clientes e motores de busca que o recurso foi movido permanentemente, então caches e reescritores de links podem substituir a URL original. Um 302 Found (originalmente 'Moved Temporarily') indica um redirecionamento temporário — a URL original deve ser usada no futuro. Para redirecionamentos que preservam o método, os códigos 308 (permanente) e 307 (temporário) são geralmente preferidos em vez de 301 e 302.

  4. O HTTP/2 ainda usa linhas de status e frases de razão?

    O HTTP/2 mantém os códigos numéricos de status, mas elimina completamente a frase de razão. O status é entregue como um campo pseudo (:status: 200) e o protocolo é estruturado em binário, não em texto linha por linha. As frases de razão sobrevivem apenas no HTTP/1.x e sempre foram informativas — os clientes são obrigados a agir com base no código de status, não no texto.

  5. Por que o HTTP exige CRLF em vez de apenas uma quebra de linha?

    O HTTP herda sua convenção de terminação de linha dos protocolos de texto antigos (SMTP, NNTP, FTP) definidos na década de 1980, todos os quais usam CRLF (\r\n) como o final de linha padrão. A gramática do RFC 9112 exige CRLF entre a linha inicial, os campos de cabeçalho e a linha em branco que antecede o corpo. A maioria dos servidores é tolerante a uma quebra de linha simples, mas analisadores e proxies rigorosos podem rejeitar respostas que omitam o retorno de carro.

Quer eliminar anúncios? Fique sem anúncios hoje mesmo

Instale nossas extensões

Adicione ferramentas de IO ao seu navegador favorito para acesso instantâneo e pesquisa mais rápida

Ao Extensão do Chrome Ao Extensão de Borda Ao Extensão Firefox Ao Extensão Opera

O placar chegou!

Placar é uma forma divertida de acompanhar seus jogos, todos os dados são armazenados em seu navegador. Mais recursos serão lançados em breve!

ANUNCIADO Remover?
ANUNCIADO Remover?
ANUNCIADO Remover?

Notícias com destaques técnicos

Envolver-se

Ajude-nos a continuar fornecendo ferramentas gratuitas valiosas

Compre-me um café
ANUNCIADO Remover?