Мock HTTP Response Builder

ДанныеРазработчикНетворкинг
Реклама · УДАЛИТЬ?
Опциональное перекрытие текста причины после кода состояния.

Пользовательские заголовки

Или добавить пользовательский

Заголовки, добавленные

Еще не добавлены пользовательские заголовки. Общие заголовки (Content-Type, Content-Length, Date) автоматически добавляются на основе опций выше.

Реклама · УДАЛИТЬ?

Гид

Имитатор HTTP-ответа

Мock HTTP Response Builder

Создание структурно корректного HTTP-ответа за несколько секунд. Выберите код состояния, выберите тип тела, добавьте заголовки и инструмент выдаёт готовую строку для вставки с строкой состояния, заголовками и телом, разделёнными CRLF — идеально подходит для тестовых фиксатуры, имитационных моков, документации API и повторного воспроизведения ответов на клиенты.

Как использовать

  1. Выберите Версия HTTP (по умолчанию HTTP/1.1) и код состояния из группового выбора — например 200 OK, 404 Not Found, или 503 Service Unavailable.
  2. (Опционально) Перекрыть текст причины если требуется нестандартный текст после кода состояния.
  3. Выберите тип тела (Текст, JSON, XML, HTML, Форма или Отсутствует) и введите или вставьте тело.
  4. Переключать автоматический Content-Type, автоматический Content-Lengthи Дата заголовки, соответствующие тому, как должен отвечать ваш сервер.
  5. Добавьте любые дополнительные заголовки — выберите из общих (Cache-Control, ETag, Set-Cookie, CORS, заголовки ограничения скорости) или введите собственный пары имени/значения.
  6. Скопируйте полный ответ, скопируйте только заголовки или скачайте его как .http файл для использования в REST-клиентах, фиксатурах или инструментах воспроизведения.

Возможности

  • Групповой выбор кода состояния — Общие коды 1xx до 5xx организованы по классам, каждый из которых имеет стандартный текст причины.
  • Выбор типа тела — Автоматически заполняет соответствующий тип Content-Type (application/json, text/html, application/xml, application/x-www-form-urlencoded, text/plain), чтобы заголовки и тело оставались синхронизированными.
  • Автоматический Content-Length — Считает байты (а не символы) с использованием кодировки UTF-8, соответствующий тому, как реальные серверы вычисляют значение.
  • Заголовок IMF-fixdate Date — Генерирует стандартный временной отсчёт (например Sun, 06 Nov 1994 08:49:37 GMT) для текущего момента.
  • Общие ответные заголовки — Однокликовые шаблоны для Cache-Control, ETag, Expires, Last-Modified, Location, Server, Set-Cookie, Vary, WWW-Authenticate, Access-Control-Allow-Origin, X-RateLimit и X-Powered-By.
  • Пользовательские заголовки — Добавьте любую пару имени/значения, с живым предварительным просмотром собранного ответа.
  • Два вида вывода — Полный ответ (строка состояния + заголовки + пустая строка + тело) и только заголовки — скопируйте любой из них или скачайте полный ответ как response.http.
  • Стандартные переносы строк — Использует CRLF (\r\n) между строками, требуемое по RFC 9112.
  • – вывод и проверка обновляются в реальном времени при вводе или изменении параметров. — При каждом изменении результат пересчитывается мгновенно; не требуется кнопка отправки.
  • Работает полностью в браузере — Никаких данных не передаётся с вашего компьютера и не участвует никакой серверной платформы.

Распространенные случаи использования

  • Фиксатуры для единичных и интеграционных тестов — Вставьте результат в строку фиксатуры для requests-mock, nock, MSW, WireMock или любого HTTP-записывающего инструмента.
  • Документация API — Показать точную форму ответа (с заголовками) в примерах OpenAPI или в документации для разработчиков.
  • Отладка клиентов — Воспроизвести редкий ответ сервера (ограничение скорости, частичный контент, перенаправление) без необходимости запускать реальный бэкенд.
  • Обучение HTTP — Визуализировать формат ответа на уровне сети: строка состояния, заголовки, пустая строка, тело.
  • Ручное воспроизведение — Провести ответ в nc -l или подобный слушатель для проверки реакции клиента.

Часто задаваемые вопросы

  1. Какова структура HTTP-ответа версии 1.1?

    HTTP-ответ версии 1.1 состоит из строки состояния, нуля или более заголовков, пустой строки и опционального тела. Строка состояния — это версия HTTP, трёхзначный код состояния и текст причины, разделённые одним пробелом. Каждая строка завершается CRLF (возврат каретки + перевод строки). Пустая CRLF после последнего заголовка указывает на начало тела. Эта структура определена в RFC 9112 (последовательник RFC 7230).

  2. Что измеряет Content-Length — байты или символы?

    Content-Length — это длина тела сообщения в октетах (байтах), а не в символах. Для текста ASCII значения совпадают, но для любого UTF-8 строки с не-ASCII символами они расходятся — один эмодзи или акцентированный символ обычно занимает 2–4 байта. Вычисление Content-Length на основе количества символов в строке — одна из самых распространённых ошибок в HTTP, и она может привести к тому, что клиенты будут отсекать тело или будут ждать отсутствующих байтов.

  3. Какова разница между перенаправлением 301 и 302?

    Оба ответа включают заголовок Location, указывающий на новую URL, но семантика различается. Ответ 301 Moved Permanently сообщает клиентам и поисковым системам, что ресурс был перемещён навсегда, поэтому кэши и переписыватели ссылок могут заменить исходную URL. Ответ 302 Found (исходно «Moved Temporarily») сигнализирует о временных перенаправлениях — исходная URL должна использоваться в будущем. Для современных перенаправлений с сохранением метода, предпочтительны 308 (постоянное) и 307 (временное), а не 301 и 302.

  4. Использует ли HTTP/2 строки состояния и текстовые причины?

    HTTP/2 сохраняет числовые коды состояния, но полностью удаляет текстовую причину. Статус передаётся как псевдозаголовок (:status: 200), и протокол передаётся в бинарном формате, а не в текстовом формате, ориентированном на строки. Текстовые причины сохраняются только в HTTP/1.x и всегда были информативными — клиенты обязаны реагировать на код состояния, а не на текст.

  5. Почему HTTP требует CRLF вместо простого переноса строки?

    HTTP наследует свою конвенцию завершения строк от более старых интернет-протоколов (SMTP, NNTP, FTP), определённых в 1980-х, все из которых используют CRLF (\r\n) как стандартный конец строки. Грамматика в RFC 9112 требует CRLF между строкой начала, заголовками и пустой строкой перед телом. Большинство серверов допускают отсутствие возврата каретки, но строгие парсеры и прокси могут отклонять ответы, в которых отсутствует возврат каретки.

Хотите убрать рекламу? Откажитесь от рекламы сегодня

Установите наши расширения

Добавьте инструменты ввода-вывода в свой любимый браузер для мгновенного доступа и более быстрого поиска

в Расширение Chrome в Расширение края в Расширение Firefox в Расширение Opera

Табло результатов прибыло!

Табло результатов — это интересный способ следить за вашими играми, все данные хранятся в вашем браузере. Скоро появятся новые функции!

Реклама · УДАЛИТЬ?
Реклама · УДАЛИТЬ?
Реклама · УДАЛИТЬ?

новости с техническими моментами

Примите участие

Помогите нам продолжать предоставлять ценные бесплатные инструменты

Купи мне кофе
Реклама · УДАЛИТЬ?