I feel like that might be more useful than what appears to be just a special-purpose varnish/squid
Re AMQP, I want to mention that our Zurl project does something similar, but with ZeroMQ. It leads to some interesting possibilities: http://blog.fanout.io/2014/02/18/fun-with-zurl-the-http-webs...
Zurl is not an HTTP proxy though, but a ZeroMQ gateway. Templar with async responses would be much more generally useful to HTTP developers.
1. "Fire and forget" ability. It would be great if I could send a request through Templar with an X-Templar-Fire-And-Forget: 1 HTTP header which means "deliver the request in your own time, but return a 200 OK to my client straight away so I don't have to wait for it.
2. It would be great if it could "validate" the URLs going through it somehow. When sending webhooks, it's important to be sure that they are going to the rest of the internet and not being used to probe internal IPs/hostnames of your own infrastructure. This is a bit of a fiddly problem, which is why it would be nice to have a proxy like Templar take it on. Take a look at the blocked_hosts section in http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib... for an example. I'm not sure how this would translate into X-Templar HTTP headers though.
One possible snag: I heard from a co-worker that if you are running on EC2 and you make an HTTP request to another site that coincidentally is also hosted on EC2 that traffic can sometimes be routed over a private IP range.
Could you possibly provide more details of how you avoid this?
An attacker would have to be already within your private network, and if they were, they could observe the traffic in plain text already.
I think the confusion is around where Templar sits in relation to your app making HTTP API calls and the services you want to talk to. I'm going to draw up a diagram to help explain this better.
What can Templar do for me that, say, nginx can't? All else equal, if nginx is already in my stack and Templar is not, why do I want to adopt Templar, or indeed even look twice at it?
From timeouts to caching, one Templar can be used for all different kinds of upstream APIs.
Again, though, maybe I'm just missing the point here. Perhaps it would help to know what use case prompted Templar's development.
Does Templar implement SSL Termination ?
Thanks for sharing this!
That cache time could be as long as 5 seconds, so that Templar is checking pretty often if the upstream has changed.
Personally, I'd rather gain the necessary control through the request mechanisms, but for a quick-and-dirty solution, this would probably work pretty well.
Because a cache is best when it's populated often, it make sense to put that into a service that many different processes on different machines can use.
Everything within templar can be done by adding capabilities to client libraries, no argument. But most client libraries don't provide these capabilities in one programming language, let alone many of them. By having the functional available as a service, Templar provides these capabilities fairly transparently (and even more transparently in the future when there is per/host and per/url configuration).
What is your concern about the url used? That they point at something a user is trying to coerce you to hit? If so, that could be a public IP too..