Toxy, a hackable HTTP proxy to simulate failure scenarios(github.com)
github.com
Toxy, a hackable HTTP proxy to simulate failure scenarios
https://github.com/h2non/toxy
12 comments
Similar project: http://greim.github.io/hoxy/ - It also has throttling and latency simulation, but not as fine-grained. It's focus is more generally on debugging and traffic manipulation.
Similar project: https://github.com/bouncestorage/chaos-http-proxy
On linux netem can help you do something similar. It is also faster, better tested, has more features and so on.
I guess an argument can be made about the user interface, as tc is a nightmare. :-)
I guess an argument can be made about the user interface, as tc is a nightmare. :-)
A somewhat related tool that is also very useful is mitmproxy.
Please make airbnb run this. Their site is such utter cow dung on a flaky connection. It would cache broken assets, they must test with a 1G connection to the colo.
Similar project: https://vaurien.readthedocs.org
is there a "verbose" option?
This is amazing! It would work very well with any API gateway like KONG [1], especially to test unexpected network conditions for our internal APIs.
[1] https://github.com/Mashape/kong
[1] https://github.com/Mashape/kong
This looks suspiciously similar to https://github.com/Shopify/toxiproxy which is an older project. It even uses similar naming "toxic" "poisons".
Suspicious seems inappropriately sinister. The project you linked is a go project, the OP is JavaScript. Imitation is the most sincere form of flattery.
Would it be possible to sort traffic by L2 or L3, and only apply to certain MACs or IP addresses? I can see that being very useful for PXE and provisioning in "cloud" environments.
You can create your own rule to do that, for instance, inspect the request remote connection address.
Then, you can apply that rule to the bandwidth poison. The poison will be only applicable if the rule passes.
Then, you can apply that rule to the bandwidth poison. The poison will be only applicable if the rule passes.
Along with this and Kong there is also https://github.com/mailhog/MailHog for testing SMTP failure scenarios on outgoing email.
I wrote a similar thing to this too: https://github.com/hitchtest/hitchsmtp#bad-smtp-server
It just outputs the mail it receives to stdout as JSON for easy parsing. Sending to specific email addresses "e.g. [email protected]" will trigger specific SMTP errors.
It just outputs the mail it receives to stdout as JSON for easy parsing. Sending to specific email addresses "e.g. [email protected]" will trigger specific SMTP errors.
Basically, DNS injection for a machine would mean no noticeable difference in HTTPS.