¿Odias los anuncios? Ir Sin publicidad Hoy 

Constructor de respuesta HTTP ficticia

DatosDesarrolladorRedes

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

Versión HTTP

Código de estado

Frase de razón

Sobrescripción opcional del texto de razón después del código de estado.

Tipo de cuerpo

Cuerpo

Establecer automáticamente el Content-Type a partir del tipo de cuerpo

Calcular automáticamente el Content-Length

Incluir el encabezado Date (hora actual)

Encabezados Personalizados

Añadir Encabezado

Valor

O añadir personalizado

Nombre del Encabezado

Valor del Encabezado

Encabezados agregados

No se han agregado aún encabezados personalizados. Los encabezados comunes (Content-Type, Content-Length, Date) se agregan automáticamente según las opciones anteriores.

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Construir un generador de respuesta HTTP ficticio

Constructor de respuesta HTTP ficticia

Construye un mensaje de respuesta HTTP estructuralmente correcto en segundos. Elige un código de estado, selecciona un tipo de cuerpo, agrega encabezados y el herramienta emite una cadena lista para pegar con la línea de estado, encabezados y cuerpo separados por CRLF — ideal para fijos de prueba, mocks de integración, documentación de API y retransmisión de respuestas frente a clientes.

Cómo Usar

Elige el Versión HTTP (predeterminado a HTTP/1.1) y un código de estado del selector agrupado — por ejemplo 200 OK, 404 Not Found, o 503 Service Unavailable.
(Opcional) Sobrescribir el texto de razón si se necesita un texto no estándar después del código de estado.
Elige un tipo de cuerpo (Texto plano, JSON, XML, HTML, Formulario o Ninguno) y escribe o pega el cuerpo.
Palanca contenido automáticamente de Content-Type, contenido automáticamente de Content-Lengthy Fecha encabezados para que coincidan con cómo respondería tu servidor.
Agrega cualquier encabezado adicional — elige entre encabezados comunes (Cache-Control, ETag, Set-Cookie, CORS, encabezados de límite de velocidad) o escribe un par nombre/valor personalizado.
Copia la respuesta completa, copia solo los encabezados o descárgala como un .http archivo para su uso en clientes REST, fijos o herramientas de retransmisión.

Características

Selector agrupado de códigos de estado – Códigos comunes de 1xx hasta 5xx organizados por clase, cada uno con su frase de razón estándar.
Selector de tipo de cuerpo – Rellena automáticamente el tipo de contenido correspondiente (application/json, text/html, application/xml, application/x-www-form-urlencoded, text/plain) para mantener los encabezados y el cuerpo sincronizados.
Contenido automáticamente de Content-Length – Cuenta los bytes (no caracteres) usando codificación UTF-8, coincidiendo con cómo calculan los servidores reales el valor.
Encabezado IMF-fixdate Date – Genera una marca de tiempo estándar (por ejemplo Sun, 06 Nov 1994 08:49:37 GMT) para el momento actual.
Encabezados comunes de respuesta – Presets de un clic para Cache-Control, ETag, Expires, Last-Modified, Location, Server, Set-Cookie, Vary, WWW-Authenticate, Access-Control-Allow-Origin, X-RateLimit y X-Powered-By.
Encabezados personalizados – Agrega cualquier par nombre/valor, con vista en tiempo real de la respuesta compilada.
Dos vistas de salida – Respuesta completa (línea de estado + encabezados + línea en blanco + cuerpo) y solo encabezados — copia cualquiera o descárgala como response.http.
Formato correcto según especificación – Usa CRLF (\r\n) entre líneas, el terminador de línea exigido por RFC 9112.
Actualizaciones en tiempo real – Cada cambio recalcula la salida instantáneamente; no se necesita un botón de envío.
Funciona completamente en tu navegador – No se envía ningún dato fuera de tu máquina y no se involucra ningún backend.

Casos de uso común

Fijos para pruebas unitarias e integración – Pega la salida en un fijo de cadena para requests-mock, nock, MSW, WireMock o cualquier grabador HTTP.
Documentación de API – Muestra una forma exacta de respuesta (con encabezados) en ejemplos de OpenAPI o en documentación para desarrolladores.
Depuración del cliente – Reproduce una respuesta rara del servidor (limitada, contenido parcial, redirección) sin necesidad de poner en marcha un backend real.
Enseñanza de HTTP – Visualiza el formato en la red de un mensaje de respuesta: línea de estado, encabezados, línea en blanco, cuerpo.
Reproducción manual – Píe la respuesta en nc -l o un similar listener para probar cómo reacciona un cliente.

 Preguntas frecuentes

¿Cuál es la estructura de un mensaje de respuesta HTTP/1.1?

Una respuesta HTTP/1.1 consiste en una línea de estado, cero o más campos de encabezado, una línea en blanco y un cuerpo opcional. La línea de estado es la versión HTTP, el código de estado de tres dígitos y una frase de razón separados por espacios simples. Cada línea termina con CRLF (retorno de carro + salto de línea). La línea en blanco después del último encabezado marca el inicio del cuerpo. Esta estructura está definida en RFC 9112 (el sucesor de RFC 7230).
¿Qué mide realmente Content-Length, bytes o caracteres?

Content-Length es la longitud del cuerpo del mensaje en octetos (bytes), no en caracteres. Para texto ASCII los dos valores coinciden, pero para cualquier cadena UTF-8 que contenga caracteres no ASCII divergen — un emoji o una letra acentuada típicamente usa 2 a 4 bytes. Calcular Content-Length a partir del conteo de caracteres de una cadena es una de las fallas más comunes en HTTP y causará que los clientes truncan el cuerpo o esperen indefinidamente por bytes faltantes.
¿Cuál es la diferencia entre una redirección 301 y una 302?

Ambas respuestas incluyen un encabezado Location que apunta a una nueva URL, pero los significados son diferentes. Una 301 Moved Permanently indica a los clientes y a los motores de búsqueda que el recurso ha sido reubicado para siempre, por lo que los cachés y los reescribidores de enlaces pueden reemplazar la URL original. Una 302 Found (originalmente 'Moved Temporarily') indica una redirección temporal — la URL original debe usarse en el futuro. Para redirecciones que conservan el método, 308 (permanente) y 307 (temporal) son preferibles a 301 y 302.
¿El HTTP/2 sigue usando líneas de estado y frases de razón?

El HTTP/2 mantiene los códigos numéricos de estado pero elimina por completo la frase de razón. El estado se entrega como un campo pseudo (:status: 200) y el protocolo se transmite en binario en lugar de texto lineal. Las frases de razón solo sobreviven en HTTP/1.x y siempre han sido informativas — los clientes deben actuar sobre el código de estado, no sobre el texto.
¿Por qué el HTTP requiere CRLF en lugar de un salto de línea simple?

El HTTP hereda su convención de terminación de línea de los protocolos de texto antiguos (SMTP, NNTP, FTP) definidos en los años 1980, todos los cuales usan CRLF (\r\n) como el final de línea estándar. La gramática en RFC 9112 requiere CRLF entre la línea inicial, los campos de encabezado y la línea en blanco que precede al cuerpo. La mayoría de los servidores son tolerantes ante un salto de línea simple, pero los analizadores e intermediarios estrictos pueden rechazar respuestas que omitan el retorno de carro.