Endpoints to test various SSL/TLS/X.509 stuff would be super helpful. Call would returning a stock HTTP response body, but with different changes to the SSL/TLS handshake (you will have to use different host names to do this)
We've discussed doing an "TLSBin" as you described (and still might) but it's a lot of work. We'd gladly sponsor one! This is something I wish Qualys/SSL Labs would do.
I've wanted the ability to combine things – e.g. setting headers on a non-200 response. It'd be nice if there was a way to combine supported options into a single request or at least as many as will fit in to the querystring.
I tend to use http://requestb.in/ since it's a lot simpler to use. Basically press on the button in the middle, copy+paste url and then reload page once webhook is there.
Also, I created this nifty shorthand for use in the terminal:
alias bin_me="curl --silent -X POST http://requestb.in/api/v1/bins | jq -r '\"http://requestb.in/\(.name)?inspect\"'"
Requires JQ (could easily not require that) and you'll just remove the ?inspect when you want to use the bin.
This solves a problem that requestb.in does not. Namely, endpoints that predictably return various HTTP headers or HTTP content. This isn't about just testing to see what your app is sending. This is about testing how your application or HTTP client or whatever handles various weird HTTP responses and features.
If I need to test how my application responds to a relative URL in a Location header, I can hit the /relative-redirect/:n endpoint. Same for Absolute urls via /absolute-redirect/:n. The If-Not-Modified stuff is also helpful.
This is a great service and I think it was the idea that then spawned another service - http://mockbin.org.
Funnily enough I use both depending on what I'm trying to achieve, with httpbin being more immediate and mockbin being for more in-depth/complex testing. Good job!
It was hosted in an EU-based datacenter on Heroku (to reduce latencies, not for any specific privacy reasons), but I need to check to see if we are still hosting it there.
Ah, okay. Because of the way it is listed I thought it was some protocol extension or other HTTP-related speciality, not a different location. Thanks for clearing that up.