Ability to stop intercepting a source

[evanholt1]

There should be a way to stop/disconnect intercepting a source on-demand.

For example, I usually need to intercept multiple sources, then later stop needing to intercept one source or another. I have not found any way to stop interception other than closing the source itself, which is often inconvenient.

Please forgive me if this has already been answered, I have searched in the docs & issues, but not yet found anything related.

---

Does this affect you too? Click below and add a 👍 to vote for this and help decide where HTTP Toolkit goes next, or go vote on the other most popular ideas so far.

[nutterthanos]

A source as in an domain or an specific url from an domain?

and if an domain you already can in settings but i think that only works if you pay for pro.

Or is it like an button on the view page on any request/response that you want that would like temporary or permanently block the domain essentially adding it to the TLS Passthrough?

[evanholt1]

@nutterthanos a source as in any of the options in the intercept tab; chrome, global chrome, attach to jvm, android device via adb, etc..

I believe having a disconnect button from the intercept tab connected sources itself will be helpful in disconnecting one or more sources from the HTTP Toolkit app itself.

[JeroenBakker]

I'm also interested in this, I usually intercept a container or existing terminal to debug something and when I'm done I close HTTP toolkit resulting in all following network calls from that container/terminal failing due to the proxy being stopped.

Would be great if there was an easy way to stop the interception without having to restart the container or terminal.

[pimterry]

Interesting! Yes, it's a good suggestion. Right now some of the functionality for this already exists, but it's only used during shutdown: when you close an HTTP Toolkit window, it will try to stop intercepted browsers, disconnect Android devices, shutdown Docker containers etc (because all of them will become unusable without the proxy running).

It's not always possible though - e.g. for existing terminals we don't actually have control of the process because it was a terminal started elsewhere, so there's not much we can do (ideas welcome if you have a good way to handle this though).

Currently that's always on a proxy-port basis - e.g. "shutdown all Docker containers dependent on proxy port 8000", but it could be extended to individual targets in most cases. To see how that works, take a look at the deactivate method in each interceptor implementation in https://github.com/httptoolkit/httptoolkit-server/tree/main/src/interceptors.

I'd be interested in supporting this more properly. To do so we'd need to:

• Add a more detailed deactivate implementation in the server for each interceptor where you can precisely target things from a list, to pick which you want to close (e.g. Docker containers, Android devices) and implement that on a per-item basis.
• Probably expose some kind of 'deactivable' state in the interceptor metadata, so the UI knows what items are available that can be shut down.
• In the UI, detect when something is deactivable, and show a nice UI button to do so.

Note that 'Connected Sources' is currently a bit simplistic and wouldn't neatly line up with this: it just groups sources by user agent info in most cases, which means you might see multiple lines for the same thing (one Docker container making requests with both Ruby & Python with be two sources) or only one line for many things (multiple terminals sending with curl will appear as one curl source). We could change that though if the server exposed info about deactiveable targets, or we could make a separate UI elsewhere (e.g. stop buttons within the Docker container selector list).

UX ideas very welcome and PRs towards the above very welcome! I'm not going to be able to start working on this myself in the short term, but feel free to investigate any of the above and ask questions here or open PRs if you're interested (note that Pro is free for all contributors).

As a short-term workaround in the meantime, you can probably do this by using multiple sessions: open a separate HTTP Toolkit for each thing you want to intercept, intercept via that window and then close the window (which should try to shut down the source) when you're done. Each window takes a different port and they can all intercept independently in parallel. It's not perfect UX and it's not very discoverable, but that might work for some cases.

[mcqj]

When intercepting an exiting terminal, we can copy a command that runs a script to do the intercept.
It would be great to also be able to copy a command that runs a script to stop the interception in that same terminal.

[nutterthanos]

When intercepting an exiting terminal, we can copy a command that runs a script to do the intercept. It would be great to also be able to copy a command that runs a script to stop the interception in that same terminal.

essentially all it does is add only to said terminal is some environment variables

technically you could easily make an script that does that or if anyone here knew then an button in their own local copy of httptoolkit from its source code in the ui/backend or whatever

[pimterry]

When intercepting an exiting terminal, we can copy a command that runs a script to do the intercept.
It would be great to also be able to copy a command that runs a script to stop the interception in that same terminal.

This is a good idea actually, and I think it's fairly easy to do, without even needing to copy another command. The terminal setup scripts that power this for Bash/Fish/Powershell existing terminals are here. The copied command just pulls the appropriate script and runs it in the terminal. We could:

• At the start of each of those scripts, capture the current env vars
• Then define a stop_interception() function that clears all the env vars we set and restores the original values (note that we can't just drop all vars completely - we do need the original values e.g. for $PATH and similar)
• At the end of each script, it currently prints "HTTP Toolkit interception enabled" - we could easily add a message here saying "(Run stop_interception to disable)"

Does that make sense? I'd be happy to include this, PRs welcome. While it would be nice to do all three shells, it's not strictly required to do the same for all 3, so PRs for any one of these individually would be fine.

[mcqj]

That absolutely makes sense - I'll take a look at the code and try to find the time for a PR.

[pimterry]

The awesome @xKiian has now very helpfully implemented this for existing terminal powershell interception, in httptoolkit/httptoolkit-server#125! That will be live in the next server release, coming soon. PRs for other terminal options (or any other targets) very welcome 😄

[nutterthanos]

@nutterthanos a source as in any of the options in the intercept tab; chrome, global chrome, attach to jvm, android device via adb, etc..

I believe having a disconnect button from the intercept tab connected sources itself will be helpful in disconnecting one or more sources from the HTTP Toolkit app itself.

i would include having it for domains too

[pimterry]

I would include having it for domains too

@nutterthanos how would that work? HTTP Toolkit intercepts all traffic from a client, regardless of domain. Do you just want to filter out traffic for some domains? You can do that easily with hostname!=example.com.

Alternatively, it is possible to do this for TLS traffic using TLS passthrough in the Pro settings, where the traffic to a given hostname is tunnelled blindly (without TLS interception) but that only works for TLS traffic which includes an SNI (common, but plain HTTP & non-SNI traffic is also not especially unusual).

[nutterthanos]

@nutterthanos how would that work? HTTP Toolkit intercepts all traffic from a client, regardless of domain. Do you just want to filter out traffic for some domains? You can do that easily with hostname!=example.com.

i meant by essentially tls passthrough/recording passthrough like an include/exclude filter which can include wildcards like * which is different to filtering the current results on the page

otherwise there is this #614