From 1ac926d9936947e7b7e1cadaf2fcdeeda52b8c83 Mon Sep 17 00:00:00 2001
From: srdusr <99972264+srdusr@users.noreply.github.com>
Date: Tue, 19 May 2026 23:17:00 +0200
Subject: Bulk export as HAR ('E' from the history list)

Single-entry export (previous commit) covers "attach this one to a
report"; this covers the other common need - getting a batch of
captured traffic into another tool. HAR 1.2 was chosen specifically for
interop: Chrome/Firefox DevTools, Burp, Postman, and others can all
import it, which a mitmux-specific format couldn't do.

cmd/mitmux/har.go: harEntryFromDetail parses one entry's raw request/
response bytes into HAR's structured fields (method, url, httpVersion,
headers, query string, status, body) via the same net/http parsing the
proxy's own capture path and prettyResponse already use elsewhere in
this codebase - reused, not reimplemented. A binary body is base64-
encoded (HAR's "encoding" field) instead of passed through as a JSON
string: encoding/json replaces invalid UTF-8 with U+FFFD by default,
which would silently corrupt exactly the bodies (images, protobufs,
...) where byte-exactness matters. harDocFrom builds the full document
from a batch of entries, skipping (not failing on) any that fail to
parse - one malformed capture, e.g. a deliberately broken Repeater
request, shouldn't block exporting everything else.

'E' from the history list exports the current view - the visible,
filtered set if a search is active, everything otherwise, same
"respects the active filter" behavior 'x' delete already has and
explicitly the opposite of 'X' clear-all, which always targets
everything regardless of filter. Reuses the same modal path-prompt
state as single-entry export (exportEditing/exportInput), discriminated
by a new exportBulk bool so both share one text-input widget and
key-handling pattern rather than duplicating it. Since the list only
ever holds Summary metadata (no raw bytes), exporting has to fetch each
entry's full detail first - exportHAR does this as a sequence of Get
calls inside a single tea.Cmd, which runs in bubbletea's own command
goroutine, so the UI stays responsive through what's effectively a
blocking round trip per entry. A failed fetch is skipped the same way a
failed parse is; the status line reports the total skipped either way,
not just entries written, so a partial export is visible rather than
silently different from what was expected.

Verified live in tmux against a running daemon: exported 3 real
captured entries (including a binary PNG response) to a HAR file,
validated the output is well-formed JSON with the correct HAR 1.2
structure, and confirmed the base64-encoded image entry decodes back to
byte-identical PNG data (magic bytes checked). Separately applied a
search filter (3 entries -> 2) and confirmed 'E' exported exactly the 2
filtered entries, not all 3 - the same filter-respecting behavior the
status line and help text both claim.

go build/vet/gofmt/test/mod tidy all clean.
---
 PLAN.md | 30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

(limited to 'PLAN.md')

diff --git a/PLAN.md b/PLAN.md
index c1fc0b6..4864012 100644
--- a/PLAN.md
+++ b/PLAN.md
@@ -253,11 +253,31 @@ truncated, matching the Detail view's own labels) so the exported file
 carries the same trust information the UI already shows, not a blanker
 claim.
 
-Still open from the expanded "worth considering" list: bulk export
-(HAR, for interop with other tools), copy-as-curl, and scope/target
-filtering (to keep noise - trackers, CDNs, unrelated third-party
-hosts - out of history and search). All requested explicitly; none
-started yet.
+Shipped since: bulk export. `E` from the history list exports the
+current view (respecting an active search filter - explicitly the
+filtered set, not always everything, unlike `X` clear-all which is
+deliberately the opposite) as a HAR 1.2 file, chosen specifically for
+interop: DevTools, Burp, Postman, and others can all import it, which a
+mitmux-specific format couldn't do. Building it means parsing each
+entry's raw request/response bytes back into structured HAR fields
+(method, url, headers, status, body) via the same net/http parsing the
+capture path and prettyResponse already use - reused, not
+reimplemented. A binary body is base64-encoded (HAR's "encoding" field)
+rather than passed through as a JSON string, which would silently
+corrupt it: encoding/json replaces invalid UTF-8 with U+FFFD by
+default, exactly the failure mode that would quietly corrupt an
+exported image or protobuf body with no error anywhere. An entry that
+fails to fetch (daemon round trip) or parse (a deliberately malformed
+Repeater request, say) is skipped rather than aborting the whole
+export - the status line reports how many, so a partial export is
+visible, not silent.
+
+Still open from the expanded "worth considering" list: import (no path
+back in yet - HAR export was prioritized as the more common daily need,
+getting captured evidence OUT for a report or another tool, over
+bringing traffic IN), copy-as-curl, and scope/target filtering (to keep
+noise - trackers, CDNs, unrelated third-party hosts - out of history
+and search). All requested explicitly; none started yet.
 
 Skipped deliberately (from the research, matches this tool's stated
 scope): active/passive vulnerability scanning, plugin marketplace,
-- 
cgit v1.2.3