Page Comparison

...

WrapperConfig is built on a magics base. By means, WrapperConfig can preconfigure data that is not normally supported by the wrapper. Eeven if it is currently mostly untested, you can simply use either setOption to prepare data that should be passed through to curl, or your own set-call. For example using code that looks like this:

$config = (new WrapperConfig())->setProxy('proxy-data');
$curlWrap = (new CurlWrapper())->setConfig($config);

$wrapper = new CurlWrapper();
$currentConfig = $wrapper->getConfig();
$currentConfig->setProxy('proxy-data');
$curlWrap = $wrapper->setConfig($currentConfig);

However, while this library is being built, proxy- and ip configuration will be a part of WrapperConfig. The magics idea will however keep the codebase and "IDE helpers" quite clean. An already implemented example is the timeout. See below in the supported magics section.

...

Throwables in WrapperConfig is based on web traffic and returned headers. In the default state, everything that returns HTTP 400 - 599 are considered throwables and will throw an exception if returned from a http request. There is a slight differense here though, since netcurl 6.1 uses an improved errorhandler. For example, the curlwrapper no longer needs to be instatiated in the same way as 6.0 required to extract exceptions from the responses. For 6.0, you had to do something like this:

$instance = new MODULE_CURL();
try {
    $request = $instance->doGet('url');
} catch (Exception $e) {
    // Extract responses from the primary instance as $request will not be available during an exception.
    $instance->getBody();
}

Instead the errorhandler makes this possible (taken from the unittest getThrowablesByBody):

use TorneLIB\Exception\ExceptionHandler;

try {
    // A shorter example of a request that returns a body with json-content.
    $curlWrapper = new CurlWrapper()->request('url');
} catch (ExceptionHandler $e) {
    $curlWrapperException = $e->getExtendException()->getParsed();
}

...