If you need to make many requests at once but feel that you don't want to regenerate or reuse the wrapper for each request, you can use the internal support for curl_multi-requests. This feature is limited to the CurlWrapper and is currently not tested through NetWrapper. However, it should be able to use the NetWrapper out of the box. However, if the curl driver isn't available and you are using the NetWrapper, this will never happen either. This is not automated, and could also break the way netcurl works if you're using this feature outside the CurlWrapper.
6.1.3 and below
In 6.1.3 and prior versions the default request syntax looks like this:
For each url, you can then use this syntax to get each response from the urls:
The most important rule for those requests is that your urls has to be unique. For example, you can't repeat your request like this:
This is caused by the fact that we use associative requests to fetch each url via the multi request.
6.1.4 and above
As of 6.1.4, the multi-requests has been extended, so each request can be configured separately. By means, if you use the above syntax, multiple requests should work mostly as it always have. The different is that the request-method now supports extended data.
Is the unittests we have an example ready for this:
As you can see in the above example, each url is extended with a non-associative for each request being made. This means that all urls also are based on indexed arrayed instead of the urls stored as keys. This opens up for partially configurable curl_multi-requests. See the list of parameters below. The multi-request here is limited in the way that most data will fall back to global settings when not set. Also, you can currently not configure SSL separately for each curl session. Nor you can't set up separate curloptions, as the handles are set deeper in the core. It is considered, but since this method has been built for a specific reason, this wasn't planned this time.
The syntax very much looks like how the request()-method is actually built.
Each response from each curlhandle should be fetched very much like how database-rows are fetched. This may be changed in the future, so that you can fetch everything as one big return-array.
One thing that is currently untested is the user authentication in the multi requests. However, the data should work like the setAuthentication()-method usually do. In the setAuthentication()-request, we primarily requesting defaults, so by not setting authentication variables for each handle, but within the normal requests userdata will be fetched for all calls. In the below code-block we're currently demonstrating how the setAuthentication() fetches its userdata by overwriting the parent variable set, from the ConfigWrapper.