# Roadmap
A loose plan for what I want httptap to do next. I don't commit to
dates. Versions are shipped when a slice feels done, not on a
calendar.
## 0.6 - current (2024-11)
What landed in this line:
- chunked transfer-encoding edge cases (`a3f8b2c`)
- scroll keybindings in the TUI viewport (`1b4d9e0`)
- arm64 support via cilium/ebpf (`f8e0a12`)
- header case normalisation (`c0912ad`)
- `--pid` repeatable and `--follow-forks` (`44bb1d7`)
If you're new, start with 0.6. It's stable, the kernel floor is 5.8,
and the default probes catch anything using OpenSSL, GnuTLS or Go's
crypto/tls. Everything below is plan, not promise.
## 0.7 - the HTTP/2 pass
The big rock. The current HTTP/2 support emits frame-level events
which is useful for seeing method+path but not enough to show request
bodies. I want:
- HPACK decode, per-flow dynamic table tracking
- stream reassembly keyed on stream id
- full request/response pairing like the HTTP/1 parser
I would put HPACK in its own package so the parser package can stay
HTTP/1-focused. Tests in `internal/parser/http2/testdata` using
well-known h2c captures.
HTTP/3 is out of scope for 0.7. QUIC packet numbers, ACK ranges,
retransmits - that is a research project.
## 0.8 - export and integrate
A set of small features that people have asked for and that fit
together:
- `--jsonl` flag streams parsed flows as newline-delimited JSON
instead of or alongside the TUI
- `--har` flag writes a HAR file on exit (or periodically)
- clipboard `y` gets a sibling `Y` that yanks as HAR for paste into
Charles/Proxyman
- a minimal stdout mode (`--no-tui`) for people piping into other
tools
None of this changes the kernel side. All of it is rendering variants
on the same parsed flow.
## 0.9 - BoringSSL and uncommon builds
Auto-detect BoringSSL. Right now you have to pass `--probe SSL_read:path`
manually when the target is linked against BoringSSL. The symbols are
there, the ABI is compatible, the detection is the missing piece.
I also want to handle statically linked TLS libraries better. Envoy
and some proxies bundle BoringSSL into the binary; we need symbol
resolution that looks inside the binary first.
## 1.0 - polish
Nothing exotic; I would cut 1.0 when:
- the CLI flags feel settled
- the JSONL schema has a version field that I am willing to not break
- the TUI has tests beyond "it compiles" (I'm not sure what that
looks like; golden-image tests maybe)
- docs are enough that someone can debug a probe-not-attaching issue
without pinging me
## Later or maybe never
These are parked because I don't have a clear design or a real user.
- Windows. `SspiEncryptMessage` hooking via ETW. I don't have a
Windows dev machine.
- Container-aware attaching. Detecting a PID is inside a container
and resolving its library paths via the host's `/proc` would be
genuinely useful, but half the work is container-runtime-specific.
- Mac via DTrace. Probably not. DTrace on modern macOS is locked down.
If someone wants to write a separate tool with the same UI that uses
Endpoint Security, I would link to it from the README.
- Replay. Parsed flows are just data; letting the user re-issue a
flow against a target would be trivial. But that's what curl is for.
## What I won't do
Some items I have been asked for and said no to:
- A proxy mode. The whole point of httptap is not being a proxy.
- A web UI. I use this from a terminal; a web UI would be an
entirely different project with different concerns.
- Persistent storage. Live inspector only. If you need durable
capture, combine `--jsonl` with `jq` or clickhouse.
## How to help
Look through [CONTRIBUTING.md](/src/httptap/contributing-md/). The
parser is the friendliest place to dig in: it's pure functions over
byte streams, easy to test, and there are real bugs left. The BPF
side is smaller but the iteration loop is slower (kernel version
matrix, verifier messages) so start elsewhere unless you're already
comfortable with libbpf.