-
Notifications
You must be signed in to change notification settings - Fork 449
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(upstream) toxic for http headers #215
base: main
Are you sure you want to change the base?
Conversation
Actually, I think most of the work on bidirectional toxics was done, it just needed some review and polishing. I got stalled and stopped working on it, but I could put the time in if there's interest. I'd love for toxiproxy to start supporting protocol aware toxics, since I think it's a powerful tool, and would have a lot of applications. |
Just FYI for people looking here for a HTTP toxic, I found a different way of delaying HTTP requests and returning errors by using https://www.mocky.io/, you can specify a HTTP status code and you can pass ?mocky-delay to the url to have a delay in the response |
Hey Toxiproxy team, |
Regarding bidirection toxics, as @xthexder explained the work is mostly done. Someone needs to own understanding + polishing + shipping it. Currently no one is owning that work though. (#132) Regarding this PR, I don't see the issue with adding a "hackier" short term solution in Toxic form. Especially since toxics are well de-coupled from the rest of the system. We should get this PR reviewed. |
Hi folks! Is there still interest in this? |
Hi @worldtiki, I was trying out this toxic, but not able to pass headers as an attribute, there is a problem in unmarshalling. I wanted to know how were you creating this toxic using the CLI. Error I am getting |
@worldtiki : Sorry the PR got accidentally closed when the branch got renamed. I have reopened the PR and updated the source. |
Raising this pr and hoping to get some traction on Toxiproxy again :)
Context: it's common to use the host header to direct a http request to a particular service, specially when using load balancers/reverse proxies. This is a problem with toxiproxy as the victim app will be configured to send the requests to localhost:port and when toxiproxy forwards it to the reverse proxy the host header will be localhost and the request will fail to be delivered to the correct service.
This toxic is an upstream toxic only and allows forcing http headers for a proxy (host and others). I understand there's been some discussion about bidirectional toxics but that work was not done yet, and I think it would be of interest to solve this issue now and refactor this solution later to add downstream support