Show HN: HTTP Mock – Intercept, debug and mock HTTP(S) with zero setup

For that terminal interception, HTTP Toolkit injects a lot of environment variables, including adding some wrappers to your path, which allow it to inject into a _lot_ of places. It sets `SSL_CERT_FILE` for example, which reconfigures the default CA for any processes started from that terminal that use OpenSSL. Again, all scoped to just this one terminal window.

In the case where you specifically manage the trust store as you describe I suspect that'll break (the requests will fail, but they'll still appear in HTTP Toolkit as just 'Certificate rejected for ABC.com', without the full details). The vast majority of applications don't do that though; they rely on the environment to tell them who to trust, and HTTP Toolkit creates the environment. For specific cases that don't, I also include a bunch of extra overrides and injections, so if there's anything that comes up that doesn't fit it's fairly easy to work around it.

It's all open-source, so you can look through the specifics if you like. The core terminal interception setup logic is https://github.com/httptoolkit/httptoolkit-server/blob/maste.... That spawns a terminal and injects the environment variables from https://github.com/httptoolkit/httptoolkit-server/blob/maste..., which notably add a bunch of things from https://github.com/httptoolkit/httptoolkit-server/tree/maste... to your PATH/PYTHONPATH/RUBYLIB/etc.

It's really just the runnable desktop app part that's AGPL. That encumbers you if you're making a directly derivative work (no running off with the whole app but closing the source, thank you), but otherwise it shouldn't limit you at all. This isn't like using a (A)GPL library in your codebase; it's a full application and you're an end user.

In practice, I'm not too worried. It's a fair bit of a hassle, as you'd have to rebuild everything yourself. It'd also require a fork that would make keeping up to date with the main versions new features painful, and it's been moving pretty quickly!

It's only a few dollars a month, if that's expensive enough for you that the time & hassle to fork the whole thing would be worthwhile, email me at tim@httptoolkit.tech and I'll just give you a free subscription.

It's a Node.js library, so you'd need a Node container and a little script to configure it. Mockttp can spin up an HTTP/HTTPS proxy configured to pass through traffic in a couple of lines, and from there you can add any other mocking rules you want (the Mock tab here is really just a UI over this) and you can subscribe to requests/responses/whatever and report that data elsewhere in any form you'd like (that's where all the data shown in the View tab here comes from).

The details get more complicated of course, but it's definitely possible.

Eventually I'm aiming for the former, I'm fairly confident there is no better method. To start with, it'll be an Android app that configures your proxy settings (acting a VPN) and walks you through adding the certificate to the user store, and for your own apps I believe that's useful already: you just need to enable user stores in your app config (https://developer.android.com/training/articles/security-con...), and everything will Just Work.

For other apps though, on new-ish Android apps it's more difficult, as you say. My plan is to try and rewrite them, _probably_ as a Pro feature, but TBC. It should be a matter of:

- Get hold of the app APK (I think you can pull it with some adb tricks, slightly unclear)

- Edit the XML config to enable the user cert store, change the app id too (so it doesn't replace or have signature conflicts with the real app)

- Repackage & reinstall the resulting APK over adb

I haven't tested this yet though, so who knows!

If you want to do intercept something manually, there's general instructions under the 'Anything' interception option. In short:

- Set the proxy on the device to point at your machine's local IP, usually on port 8000 (active port is shown under the 'Anything' option)

- Trust the generated MITM certificate on your device, so you can intercept HTTPS too (path to the certificate also shown under 'Anything').

Fundamentally, HTTP Toolkit, Charles & Fiddler are all HTTP & HTTPS proxies, so they all allow intercepting the same things, it's just a matter of how easy the setup process is.

There's the language debate to start with. E.g. Fiddler uses JScript.NET, which isn't exactly the language of choice nowadays. Realistically whatever language you choose, you have some big problems. Different groups want different tools, some want external packages, some want data stores, it's a whole thing.

It's a good point though, and I'd love to solve it. I've added an issue to my feedback repo to look at it: https://github.com/httptoolkit/feedback/issues/37. If you've got a minute, could you comment there and record the kind of scripts you'd like to write?

I'm not really sure what emulating internal authenticating proxies means in practice, for example. Are you rewriting requests to inject auth params, or validating outgoing requests, or something else?

Any chance you can export a HAR from your browser dev tools and send it to help@httptoolkit.tech? There's something very odd happening there, could be a Netlify bug.