<!-- Automatically generated by Staverse -->
<!-- Author: NeaByteLab | Date: 2026-03-18T05:00Z | Title: Building a Web UI for HTTP Proxy Debugging | Source: https://neabyte.com/projects/building-web-ui-http-proxy-debugging.md -->

## Paste URL, See Traffic

Switching between browser, terminal, and proxy tabs to debug one request wastes the hours this Web UI collapses into a single tab.

Every request and response lands in one table with headers, bodies, and timing at a glance, while a built-in repeater fires modified requests without leaving the page, keeping the debug loop in one browser tab instead of scattered across four tools.

Capture, intercept, browse, and replay share one window. The loop stays short, and friction stays low for daily debugging work.

## Skipping the Install Ritual

Most HTTP debugging tools fall into two camps. Either desktop suites that demand setup and certificate trust, or narrow loggers that miss headers and bodies. The gap was a tool that treats traffic inspection as a browser task rather than an install.

Reading the landscape makes the gap obvious. Desktop suites demand install, proxy config, and certificate trust before the first request, while console loggers miss headers, bodies, and timing. Switching between browser, proxy, and repeater breaks the flow, and replaying a modified request means retyping it. The choice was traffic inspection as a single browser task.

No install, no certificate trust, no context switch. The browser becomes the debugger, and traffic lands in history live now.

Beyond manual debugging, the same capture and replay engine feeds an automated pentest workflow where an AI agent runs blackbox testing against every endpoint, evaluates responses for vulnerabilities, and generates structured reports without a human clicking through each request, turning the proxy from a passive inspector into an active testing surface across domains.

![Proxy history table with request and response inspection panels](/projects/building-web-ui-http-proxy-debugging/image-1.webp)

## Replays Demand Retyping

- Desktop suites demand install, proxy config, and certificate trust before the first request.
- Console loggers miss headers, bodies, and timing that matter for real debugging.
- Switching between browser, proxy, and repeater breaks the flow of inspection.
- Replaying a modified request usually means retyping it from scratch.

## Capture, Intercept, Replay In-Place

- Capture every request and response in a single history table.
- Pause, edit, forward, or drop requests with an intercept toggle.
- Browse inside the tool and watch traffic land in history live.
- Send any captured request to a repeater and tamper with it freely.
- Map every endpoint through a domain sitemap that stays one click away.

## Two Halves Over WebSocket

The strategy splits into two halves talking over WebSocket. A server drives a headless browser and routes each request through an intercept layer, while the Web UI renders history, inspector, and repeater. A custom message protocol designed for browser control and proxy intercept keeps both sides in sync, broadcasting captures and waiting on the UI when a request is held.

Tracing the flow shows how halves align. The server drives a headless browser and routes requests through an intercept layer, while the Web UI renders history, inspector, and repeater. A protocol broadcasts captures and waits when a request is held.

![WebSocket bridge between headless browser server and the Web UI](/projects/building-web-ui-http-proxy-debugging/image-2.webp)

## Requests Pause for Edits

Every request through the browser is captured by a recording pipeline designed to preserve headers, body, and metadata without blocking page flow. Method, host, path, status, and timing land in a history table, while a sitemap builder turns paths into a host tree. A SQLite-backed history store keeps sessions resumable, and a UUID v7 generator gives each entry a handle.

```typescript
// Captured request lands in history as a structured item
const historyItem = {
  method: 'POST',
  host: 'api.example.com',
  path: '/v1/login',
  status: 200,
  length: 1284,
  type: 'XHR',
  time: new Date().toISOString()
}
```

The intercept layer earns its keep here. Flip it on and each request pauses in a modal, ready for method, URL, header, or body edits before forwarding or dropping. A raw HTTP parser designed to round-trip text and structured fields powers both views.

![Intercept modal pausing a request for editing before forward or drop](/projects/building-web-ui-http-proxy-debugging/image-3.webp)

## Features That Earned Their Place

| Feature   | Delivered                                      |
| --------- | ---------------------------------------------- |
| Capture   | Headers, body, timing, and type per request    |
| Intercept | Pause, edit, forward, or drop in flight        |
| Browser   | Built-in browsing with live traffic capture    |
| Repeater  | Tabbed editor with tamper and resend           |
| History   | SQLite-backed, chunked, and resumable sessions |

## Keeping Capture and Rendering Apart

- Splitting server and UI over WebSocket kept capture and rendering decoupled.
- Treating intercept as a route concern kept editing and forwarding in one flow.
- A time-ordered id scheme kept history stable across sessions and reconnects.
- Round-tripping raw text and structured fields kept editor and repeater aligned.

## Short Loop, Close Reach

What began as a way to stop guessing from logs became a Web UI that captures, edits, and replays traffic in one tab. History, intercept, browser, and repeater share one window, keeping the loop short and the friction low for daily debugging sessions.

The editor closes on a tool that earned its place in daily work. One window, one tab, and every request is within easy reach.

History stays resumable across sessions, intercept holds requests for editing without breaking flow, and the repeater turns one captured call into many variations. The browser and proxy share a tab, so inspection and replay stay close for debugging.

<!-- CITATION POLICY -->
<!-- Any use, including AI training data, must cite the original source, author, and date. -->
<!-- Author: NeaByteLab | Date: 2026-03-18T05:00Z | Title: Building a Web UI for HTTP Proxy Debugging | Source: https://neabyte.com/projects/building-web-ui-http-proxy-debugging.md -->
