mockttp
httptoolkit
Our great sponsors
mockttp | httptoolkit | |
---|---|---|
18 | 36 | |
733 | 2,409 | |
0.5% | 3.7% | |
8.1 | 4.1 | |
13 days ago | 7 months ago | |
TypeScript | ||
Apache License 2.0 | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
mockttp
-
Client-side proxies – a better way to individualise the Internet? (2000)
Interesting how the world has changed since the 2000s here - nowadays the ecosystem is far better, so it's much easier to set up tools to mess around with this, but the use of HTTPS everywhere makes it more difficult in more advanced cases (e.g. you'll often need to fight certificate configuration in individual clients).
In part because of that, browser extensions have become the main way to go for this kind of local web modification, but now there's new restrictions slowly coming in there too.
If you want to mess around with HTTP-level rewriting for yourself though, I maintain a Node.js library for easily writing tiny custom HTTP & HTTPS-intercepting proxies that makes it very easy: https://github.com/httptoolkit/mockttp/. Others have built more specific tooling on top too, like this web page modification proxy: https://github.com/OnkelTem/wmod-proxy
There's a walkthrough for setting up a quick local proxy & rewriting your own browser traffic here: https://httptoolkit.com/blog/javascript-mitm-proxy-mockttp/
-
Ask HN: Side project of more that $2k monthly revenue what's your project?
> What did the first iteration of this product look like? Was it more or less similar, or substantially different from the spirit of httptoolkit today?
Technically, the first iteration was https://github.com/httptoolkit/mockttp - an HTTP integration testing library for JS. Not a desktop app at all. I'd originally built that for testing uses, but as it matured I realised that with a UI and automated setup tools it'd be useful as a complete product (but Mockttp still powers all the internals today, and you can use it directly to build your own custom intercepting proxies too).
For the first real product, the very first public 'launch' was literally a landing page with some demos of the potential UI and a signup form, just to test interest and check it wasn't a terrible idea. The results looked promising, so that was followed a few months later by a very basic but usable free version (entirely read-only, and only supporting Chrome interception) with the freemium features on top appearing a few months after that.
> How did you go from (some semblance of a product) to first sale? / acquiring first customer?
Once I announced the paid version (a blog post to my tiny set of newsletter signups, plus a little response on HN/Reddit/Product Hunt etc) I got a handful of paying customers (but certainly less than 10) within 24 hours. Nice but not a meaningful income, and from that wild peak it dropped back down to maybe one new customer per week or so afterwards, so it was quite slow going at the start.
However, those paying customers (and the mere fact of offering a paid service generally) resulted in _much_ better feedback. Rather than "this is cool" all of a sudden I had real demands for specific features, from people with concrete use cases and money in their hands. The initial paid features were just made up off the top of my head, and honestly didn't create a particularly compelling paid feature set. It's very hard to really know what people will pay for! That feedback was incredibly unbelievably useful to fix that.
From there, building out the key features people asked for over the following 6 months boosted things very significantly, and started to get things moving for real, and then you get into a virtuous circle, where more users => more feedback => better product => more users => ...
> did you spend anything on marketing/distribution?
I tested advertising at a small scale for a few months, but it didn't really work great. I think largely because it's very very freemium - 99% of users pay nothing - so the acquisition cost for a paying user doesn't make sense, and also honestly I don't have much experience with ads and I'm not sure I'm any good at writing them.
Content marketing meanwhile has worked great, keeps passively returning dividends, and cost nothing. I've tried to fill the blog (https://httptoolkit.com/blog/) exclusively with detailed & high-value original content (detailed breakdowns of a recent HTTP security vulnerability, not "top 10 HTTP libraries for Python") which shares well on social networks for an immediate burst of traffic, and then (in most cases) provides both a long-term SEO boost and constant incoming traffic on related topics that converts into users. That starts slow, but again steadily builds up over years, if you keep working at it. Content marketing + SEO are pretty much the only marketing channels I work on right now.
-
HTTP Toolkit
I'm the author of HTTP Toolkit, I actually built the internals much earlier as an open-source library (Mockttp: https://github.com/httptoolkit/mockttp) designed for exactly the end-to-end testing mocking use case you're talking about.
It's MIT-licensed, and you can build an automated HTTP/HTTPS rewriting proxy using that in a handful of lines of JS, and script any kind of transformations or inject any responses you like.
There's a general guide to getting started here: https://httptoolkit.tech/blog/javascript-mitm-proxy-mockttp/.
For the more general interactive testing/debugging case, you can also use HTTP Toolkit itself (it has a rules builder for this kind of thing) but if you're building automation you should just use the internals directly, they have exactly the same capabilities. HTTP Toolkit just provides a UI and convenient interception setup tools over the top.
> why would I prefer this to mitmproxy?
Compared to mitmproxy, HTTP Toolkit:
- Has fully automated setup for most browsers, docker containers, Android, all Node.js/Ruby/Python/PHP/Go applications run from intercepted terminal windows, all JVM processes, any Electron apps etc etc. Some of these automated setup steps are very difficult to do manually (e.g. intercepting Android devices, where you can't normally install your own certificates nowadays, or intercepting Node.js, which completely ignores system proxy settings) so this can make a huge difference in non-trivial case.
- Supports targeted interception (intercept just one app/container/browser window) whilst all mitmproxy's manual setup steps are generally focused on helping you intercept your whole machine at once. Intercepting the whole machine means very noisy interception and means that rewriting traffic interferes with all other usage of your machine. Targeted interception means you can do neat things like run two HTTP Toolkit instances independently at the same time, and means you don't need root privileges or permanent configuration settings.
- Has generally friendlier UI & UX (imo). For example, mitmproxy uses a unique custom syntax (https://docs.mitmproxy.org/stable/concepts-filters/) of special characters to define matching & rewriting rules, or requires you to write a full python script. HTTP Toolkit lets you click 'new rule' -> 'GET requests' -> 'match regex ' -> 'then reply with ', and then immediately start injecting automated fake responses. From HTTP Toolkit you can then build named groups or these rules, and import & export them (as JSON) to build libraries you can share with your colleagues.
- Provides lots more background information automatically: e.g. built-in documentation for all standard HTTP headers, body autoformatting for lots more formats, syntax highlighting, code folding, regex searching etc of request & response bodies, plus 'this is how and why this response could be cached' caching explanations, OpenAPI-powered docs for recognized endpoints on 1400+ APIs, etc.
- Includes advanced features to do things like exporting requests as ready-to-use code for various languages & tools, or automatically testing the performance of different compression algorithms on a given response body.
- Is more easily scriptable for automation & end-to-end testing, because all the HTTP-handling internals are usable as a standalone open-source JS library: https://github.com/httptoolkit/mockttp
That said, mitmproxy has been around longer, it's definitely more mature, and it was a big inspiration in many places. It's a great project! It does have some advantages of its own:
- If you strongly prefer a CLI interface, mitmproxy is very focused on that, and HTTP Toolkit is not. HTTP Toolkit could support that too in theory (the backend & frontend are independent) but it definitely doesn't right now, and it's not high on my todo list (contributions welcome though!)
- Mitmproxy is primarily scriptable in Python. You can build automation around HTTP Toolkit's internals using mockttp, but that's JS, and it's mostly usable standalone right now, rather than integrated into normal workflows within the app. If you want very complex scripted rules, mitmproxy has a few more options right now, and lets you do things in python instead of JS, which some people will prefer.
- WebSocket debugging - this is coming for HTTP Toolkit soon, but it's not available today. WebSockets get passed through fine, but they don't appear in the UI, and you can't set up mock rules for them.
> I'd be interested both in why I'd prefer the open source httptoolkit and pro?
There's a list of Pro features at https://httptoolkit.tech/pricing/. Note that it's all open source, even the Pro code, everything.
The general idea is that everything you need to intercept, inspect and manually fiddle with traffic is totally free. Anything optional that most users don't need, but which is helpful for advanced usage or enterprise use cases, requires Pro.
-
Hudsucker: A MITM HTTP/S (and websocket) proxy
I think MITM should provide a lot of features for that please checkout mock http https://github.com/httptoolkit/mockttp
-
Docker is updating and extending our product subscriptions
Same with Telerik Fiddler recently. Good piece of software for debugging network requests on Windows.
Was free for as long as I've known it existed. Telerik recently bought by 'Progress' (ironic), software re-written in Electron and now charges a subscription to use it.
Glad HTTP Toolkit is now available free for most standard tasks - https://httptoolkit.tech/
-
Mitmproxy 7.0
I'd highly recommend https://httptoolkit.tech/ for that explorative GUI phase. I found it recently and the rule configuration, UI and interception setup is significantly better than Charles/Fiddler/Proxyman.
-
AWESOME WINDOWS TOOLS
HTTP Toolkit - HTTP debugging & mocking tool.
-
Web Weekly #8
Let's come to Frontend Developers' favourite topic: CORS requests ( Cross-Origin Resource Sharing). Tim Perry, who runs HTTP toolkit, explained what CORS and pre-flight requests are and shared how you can cache the OPTIONS request responses in multiple programming languages.
-
GraphQL the Simple Way, or: Don't Use Apollo
Apollo's packages like to move fast and break things, and each often requires specific conflicting graphql peer dependencies, making updates remarkably painful all round.
httptoolkit
- What happens when an HTTP client raises $225M at a $5.6B valuation
- Ask HN: What Underrated Open Source Project Deserves More Recognition?
-
Reversing an Android app API
HTTP Toolkit, you will need to install one in your PC and another one in the emulator.
-
Need an app that sniffs HTTP/HTTPS requests that are made by apps
Maybe not exactly what you're looking for, but if you could side-load on windows this app should work. https://httptoolkit.com/
-
Ask HN: Side project of more that $2k monthly revenue what's your project?
I run HTTP Toolkit (https://httptoolkit.com) which passed $2k a couple of years back. No longer a side project, as it's made enough money for me to work on it full time for a fair while now, but it certainly started that way, and it's still a one-man show (plus many wonderful open-source contributors).
I suspect that'll be a common theme in answers here though: if you have a side project making $2k a month, in most of the world that's enough for you to go full-time and try to take it further. If you can make $2k/month on something working only part-time, you can definitely make a lot more if you focus on it.
On your questions: HTTP Toolkit is a desktop app (plus a mobile app and other components for integrations) but it's an Electron app that effectively functions as a SaaS (with a freemium subscription model) that just happens to have a component that runs on your computer. And actually getting to $2k wasn't overnight at all - it took a couple of years of slow steady slog. A few inflection points that made a notable difference (releasing rewriting support & Android support particularly) but mostly it was a matter of "just keep pushing", trusting the trajectory would keep going, and steadily grinding upwards. It's great where it is now, but it's hard work - a solo business is not for the faint of heart!
-
I hacked Gumroad's API and broke a bunch of tools
>I guess it would be an interesting experiment to create a proxy that captures any values going out to gumroad's license verification api endpoint and change all server responses to be true instead of false. Ditto for altering the number of uses of a product in case there is a limit there too.
You don't need to create a custom proxy for that.
There are many general-purpose tools that will let you inspect HTTP/HTTPS traffic between your browser and a remote server:
-
Scraping data from an app: real world example
Previously i had some success with this https://httptoolkit.tech/ and running the app on android emulator
-
Ask HN: How to Monetize Open-Source Software?
> Monetization via Paid Premium Version / Open Core
This point is interesting, because it assumes the only way to do premium is with a closed-source version, losing the open-source benefits.
Personally I've had good success (i.e. comfortably enough income as a solo bootstrapped project that I can work on open source full time) doing a freemium approach that's 100% open-source for http://httptoolkit.tech
Yes, anybody can fork the project and remove the payment checks (here: https://github.com/httptoolkit/httptoolkit-ui/blob/5cf0b10c6...) but it's a non-trivial hassle to fork everything and hook it all up, and means ongoing maintenance work to manage a fork forever, so at the price it's not really worth any serious professional's time (and I give out free licenses for everybody would contributes to the code anyway).
Works well, lets you stay 100% open source, which is good for everybody and encourages contributions, and you can still make enough money to fund development (never going to make anybody a billionaire, but that's not the point).
-
Different response Httpie vs Httpx ( python )
It's really difficult to help you debug this. Generally my advice is to fire up man in the middle network inspector like https://httptoolkit.tech/ or https://mitmproxy.org/ and see whether those two requests are identical for sure.
- Launch HN: Requestly (YC W22) – Network debugging proxy for web and mobile
What are some alternatives?
mockoon - Mockoon is the easiest and quickest way to run mock APIs locally. No remote deployment, no account required, open source.
mitmproxy - An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers.
httpyac - Command Line Interface for *.http and *.rest files. Connect with http, gRPC, WebSocket and MQTT
Proxyman - Modern. Native. Delightful Web Debugging Proxy for macOS, iOS, and Android ⚡️
httptoolkit-server - The backend of HTTP Toolkit
frida - Clone this repo to build Frida
Express - Fast, unopinionated, minimalist web framework for node.
grpc-browser - A web UI for browsing and executing gRPC operations in your .NET application
frida-interception-and-unpinning - Frida scripts to directly MitM all HTTPS traffic from a target mobile application
wsl-environments
apollo-server - 🌍 Spec-compliant and production ready JavaScript GraphQL server that lets you develop in a schema-first way. Built for Express, Connect, Hapi, Koa, and more.