This is an unofficial chat room, if you want to reach out to the Faraday core team, join us on GitHub Discussions (https://github.com/lostisland/faraday/discussions) instead
This doesn’t mean Faraday doesn’t work with them, or that we don’t want their support in the code anymore.
It simply means we can’t afford to officially support them, mainly for lack of knowledge.
We do however welcome maintainers (not contributors, hence on a regular basis) that would like to help us reintroducing and supporting these rubies
It simply means we can’t afford to officially support them, mainly for lack of knowledge.
We do however welcome maintainers (not contributors, hence on a regular basis) that would like to help us reintroducing and supporting these rubies
anyone have any experience updating old gems dependent on an old version of faraday that's now throwing lots of deprecation errors? I have an old half-finished app I was playing with that uses the wayback (as in archive.org) gem, and I'm a little stuck. I updated the faraday + faraday middleware versions, and now it looks like the next step will be porting some code that uses Faraday::Builder to <whatever the new syntax is>. Are there any reference examples I could take a look at to understand what I might need to change to make this gem work with latest Faraday?
(wayback's last release that i forked was dependent on faraday 0.9.2)
Feel free to open an issue in the GitHub repo with more details about the warnings you’re seeing and we’ll be happy to have a look
Apart from that, all versions after 0.9.2 (including the latest 1.0.x) are supposed to be fully backwards-compatible, so you should be able to update to the latest, as far as you use Ruby 2.4+
Hey @timwis, this sounds like the perfect use case for Faraday. There’s no generic guide or way to do it as it depends on how you need to provide the API Key to the server. You can checkout our site (https://lostisland.github.io/faraday/) and particularly how to customise your request, to get started. You’re most probably looking to set a default header on all requests and can do so by passing it to your connection initializer.
Checkout the section “The Connection Object” at the bottom of this page: https://lostisland.github.io/faraday/usage/
The example shows you how to set the content-type header for all requests, you can apply the same strategy to set the header for your API key
bblimke/webmock#894 describes my code and what's going on
If you’re still experiencing issues and believe it’s related to Faraday, please feel free to share an I can have a look
I'm still using Faraday because IIRC it's used under the covers by the Elasticsearch gems :)
But I can check the code later on and confirm/deny
Agree it would be useful at least
@ZhaoZijie So unfortunately I checked the code and I can confirm there's no such helper in Faraday at the moment. I guess that's mostly because cookies are not a good practice for server-server communication. That said, I did find a gem called
faraday-cookie_jar that implemented cookies forwarding between faraday requests as a middleware.
if that's not exactly what you need, and you simply need to parse cookies, then that gem uses
http-cookie to do that, you can see how that works in the middleware on_complete function: https://github.com/miyagawa/faraday-cookie_jar/blob/master/lib/faraday/cookie_jar.rb
I hope at least this helps!
You mentioned Postman, which I'd assume is the application running on your computer, but when you say that you get "execution expired" with Faraday, where is this Ruby code running?
Is it from inside a container or outside?
You mentioned Postman, which I'd assume is the application running on your computer, but when you say that you get "execution expired" with Faraday, where is this Ruby code running?
Hi Matt, thanks for your response, it appears that docker network was the problem, I did a docker system prune and also I changed the way that I was creating the http client to block format and now It is working flawlessly
