TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Templar: A proxy to improve HTTP API interactions

68 pointsby evanphxabout 10 years ago

7 comments

akerl_about 10 years ago
Based on the first sentence of the description, I was expecting a proxy that added callback support to arbitrary APIs. I hit &quot;<a href="https://my-templar-proxy/?real_url=$x&amp;real_param_a=10&amp;callback_url=$foo&quot;" rel="nofollow">https:&#x2F;&#x2F;my-templar-proxy&#x2F;?real_url=$x&amp;real_param_a=10&amp;callba...</a>, it hits the real API and waits for the response, then hits my callback with it.<p>I feel like that might be more useful than what appears to be just a special-purpose varnish&#x2F;squid
评论 #9148803 未加载
simonwabout 10 years ago
This could be really useful for sending outbound webhooks, if it grew a couple of extra features:<p>1. &quot;Fire and forget&quot; 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 &quot;deliver the request in your own time, but return a 200 OK to my client straight away so I don&#x27;t have to wait for it.<p>2. It would be great if it could &quot;validate&quot; the URLs going through it somehow. When sending webhooks, it&#x27;s important to be sure that they are going to the rest of the internet and not being used to probe internal IPs&#x2F;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 <a href="http://search.cpan.org/~bradfitz/LWPx-ParanoidAgent-1.02/lib/LWPx/ParanoidAgent.pm" rel="nofollow">http:&#x2F;&#x2F;search.cpan.org&#x2F;~bradfitz&#x2F;LWPx-ParanoidAgent-1.02&#x2F;lib...</a> for an example. I&#x27;m not sure how this would translate into X-Templar HTTP headers though.
评论 #9149109 未加载
jfindleyabout 10 years ago
The HTTPS implementation looks dangerous at first sight - it looks like an attacker could very easily just strip the X-Templar-Upgrade out from the request, and then end up with everything being un-encrypted - without the client throwing any warnings.<p>Could you possibly provide more details of how you avoid this?
评论 #9152119 未加载
VeejayRampayabout 10 years ago
Note that this is by the excellent Evan Phoenix, creator of Rubinius, the Puma concurrent web server for Ruby and tons of other awesome projects.
评论 #9152127 未加载
aaronemabout 10 years ago
Maybe I&#x27;m missing the point here, but I&#x27;m not entirely sure I see the point here.<p>What can Templar do for me that, say, nginx can&#x27;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?
评论 #9149263 未加载
ing33kabout 10 years ago
Request collapsing looks like a nice feature . Regarding HTTPS support, I am not really sure if I understood the details mentioned in the Docs properly .<p>Does Templar implement SSL Termination ?
评论 #9152163 未加载
paulspringettabout 10 years ago
The caching part looks really interesting -- have you considered adding support for more fine-grained caching control, such as respecting etags and last-modified times?<p>Thanks for sharing this!
评论 #9152153 未加载