As detailed in issue #48, curb does not directly allow setting certain timeout options available in curl. This would have been a minor inconvenience if curb exposed curl_easy_setopt call (and corresponding multi-call, if any). Even without any CURLOPT_* constants defined I could still pass appropriate magic numbers to curl_easy_setopt and have a workaround for timeout functionality until a better solution is put in place. Currently I have no choice but to edit C extension code, followed by distributing and installing custom packages to/on a number of development and production systems.
Curb should expose curl_easy_setopt, perhaps with a warning that it is possible to break things by passing certain values to it (e.g. options that take C strings as arguments for example), for cases when it does not provide a "native" interface to some functionality.
or you send me a patch and if looks solid has some test coverage i'd add it to the next release...
I thought you might say that :)
I filed the ticket first in case the functionality already existed and I just couldn't find it.
I had a need for this as well ("delete=" and "head=" are implemented, but not "delete" and "head" to return a boolean).
yep, libcurl bindings for ruby are in need of a rewrite... i just don't have the time.
I started working on this and testing of setopt passthrough is rather tricky.
By design curb issues setopt calls when curb#perform is called, and forwarded setopts happen before that. This makes it impossible to use setopt passthrough to set an option that is explicitly supported by curb.
This, in turn, means that to test that setopt passthrough works we need to use options that are not supported by curb. This is not only a relatively small and obscure set, but one that is shrinking with time as curb gains features. It may be the case that for less frequently used value types there simply are not any options that curb does not natively handle, and so such types would be untestable.
This could be avoided by storing the options and values given to curb's setopt in a list and issuing them to libcurl after curb sets its own options. This should work reasonably well but obviously requires memory (including dynamic allocation) to store the options.
yeah my real thought here is i agree and I think the design of the original gem needs a rewrite... IMO it would better serve us to have libcurl bindings that implemented a thin passthrough over the libcurl easy/multi/shared interfaces.
Ideally, this would include the socket interfaces allowing us to use eventmachine or cool.io (maybe) as event loops... it also means a lot less C and a lot more ruby.
I have a local branch I need to push - I've had it for too long just sitting. have wanted to get this written for almost 2 years now...
Keeping this ticket open. There is a set interface now, but it's still very minimal as far as what can be set.
Hi - firstly, what a great package curb is, and language ruby is. I'm just starting out with learning ruby and using it to write some Rspec test cases for my team to use.
I'm currently having a related issue trying to setopt for Curl::CURLOPT_RESOLVE, receiving the message that setting that option is not supported.
I'm looking to replicate the following command:
curl --resolve "mytest.com:443:127.0.0.1" https://mytest.com
I have a working test that uses ssl_verify_host = false, which is working for most of my test cases, but is not working for end to end tests that need the hostname to be set.
Why on earth would you want to do that? The load balancers I'm connecting to perform logic based on the url used for the connection (SNI?) and therefore this drops my connection request.
I'm looking at invoking the command line option to do this testing at the moment, which would be a real shame.
Thank you very much for any help you can provide.