Nee. Guzzle kan elke HTTP-handler gebruiken om verzoeken te verzenden. Dit betekent dat Guzzle gebruikt kan worden met cURL, PHP's stream wrapper, sockets, en niet-blockende bibliotheken zoals React. Je hoeft alleen maar een HTTP handler te configureren om een andere methode te gebruiken om verzoeken te verzenden.
Noot
Guzzle heeft in het verleden alleen cURL gebruikt om HTTP-verzoeken te verzenden. cURL is een geweldige HTTP-client (misschien wel de beste), en Guzzle zal het blijven gebruiken het standaard blijven gebruiken wanneer het beschikbaar is. Het is zeldzaam, maar sommige ontwikkelaars hebben geen cURL niet op hun systeem geïnstalleerd hebben of tegen versiespecifieke problemen aanlopen. Door verwisselbare HTTP handlers toe te staan, is Guzzle nu veel meer aanpasbaar en in staat om zich aan te passen aan de behoeften van meer ontwikkelaars.
Ja. U kunt de requestAsync, sendAsync, getAsync gebruiken,
headAsync, putAsync, postAsync, deleteAsync, en patchAsync
methodes van een client om een asynchroon verzoek te versturen. De client zal een
GuzzleHttpHypromiseInterface object. Je kan then
functies afleiden van de belofte.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$promise->then(function ($response) {
echo 'Got a response! ' . $response->getStatusCode();
});
Je kan een asynchrone respons forceren om te voltooien door gebruik te maken van de wait() methode van de geretourneerde belofte.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$response = $promise->wait();
cURL biedt een enorm aantal aanpasbare opties. Terwijl Guzzle veel van deze opties normaliseert over verschillende handlers, zijn er zijn er momenten dat je aangepaste cURL opties moet instellen. Dit kan worden bereikt door een associatieve array van cURL instellingen door te geven in de curl sleutel van een verzoek.
Stel bijvoorbeeld dat u de uitgaande netwerkinterface die met een cliënt wordt gebruikt, moet aanpassen.
$client->request('GET', '/', [
'curl' => [
CURLOPT_INTERFACE => 'xxx.xxx.xxx.xxx'
]
]);
Als u asynchrone verzoeken met cURL multi handler gebruikt en het wilt tweaken,
extra opties kunnen worden gespecificeerd als een associatieve array in de
options sleutel van de CurlMultiHandler constructor.
use GuzzleHttp\Client;
use GuzzleHttp\HandlerStack;
use GuzzleHttp\Handler\CurlMultiHandler;
$client = new Client(['handler' => HandlerStack::create(new CurlMultiHandler([
'options' => [
CURLMOPT_MAX_TOTAL_CONNECTIONS => 50,
CURLMOPT_MAX_HOST_CONNECTIONS => 5,
]
]))]);
Je kan aangepaste stream context opties door gebruik te maken van de stream_context sleutel van de request optie. De stream_context array is een associatieve array waar elke sleutel een PHP transport is, en elke waarde een associatieve array van transportopties is.
Laten we bijvoorbeeld zeggen dat u de uitgaande netwerkinterface die met een client wordt gebruikt moet aanpassen en zelfondertekende certificaten moet toestaan.
$client->request('GET', '/', [
'stream' => true,
'stream_context' => [
'ssl' => [
'allow_self_signed' => true
],
'socket' => [
'bindto' => 'xxx.xxx.xxx.xxx'
]
]
]);
U moet het pad op schijf specificeren naar de CA-bundel die door Guzzle wordt gebruikt om het peer-certificaat te verifiëren. Zie verify.
Maximum function nesting level of '100' reached, aborting
U kunt deze fout tegenkomen als u de XDebug-extensie hebt geïnstalleerd en u veel verzoeken in callbacks uitvoert. Deze foutmelding komt specifiek van de XDebug-extensie. PHP zelf heeft geen functie nesting limiet. Verander deze instelling in uw php.ini om de limiet te verhogen:
xdebug.max_nesting_level = 1000
Dit kan om een aantal redenen gebeuren, maar als je PUT, POST, of
PATCH verzoeken met een Expect: 100-Continue header, zal een server die deze header niet
deze header niet ondersteunt, zal een 417 antwoord terugsturen. Je kan dit omzeilen door
de expect verzoekoptie op false te zetten:
$client = new GuzzleHttp\Client();
// Disable the expect header on a single request
$response = $client->request('PUT', '/', ['expect' => false]);
// Disable the expect header on all client requests
$client = new GuzzleHttp\Client(['expect' => false]);
U kunt het bijhouden van omgeleidde URI's en statuscodes inschakelen via de
track_redirects optie. Elke doorverwezen URI en status code zal opgeslagen worden in de
X-Guzzle-Redirect-History en de X-Guzzle-Redirect-Status-History
header respectievelijk.
De URI van het initiële verzoek en de uiteindelijke statuscode worden niet meegenomen in de resultaten. Met dit in gedachten zou je gemakkelijk het volledige omleidingstraject van een verzoek moeten kunnen traceren.
Bijvoorbeeld, stel dat u omleidingen moet bijhouden en beide resultaten samen in één rapport moet opnemen:
// First you configure Guzzle with redirect tracking and make a request
$client = new Client([
RequestOptions::ALLOW_REDIRECTS => [
'max' => 10, // allow at most 10 redirects.
'strict' => true, // use "strict" RFC compliant redirects.
'referer' => true, // add a Referer header
'track_redirects' => true,
],
]);
$initialRequest = '/redirect/3'; // Store the request URI for later use
$response = $client->request('GET', $initialRequest); // Make your request
// Retrieve both Redirect History headers
$redirectUriHistory = $response->getHeader('X-Guzzle-Redirect-History')[0]; // retrieve Redirect URI history
$redirectCodeHistory = $response->getHeader('X-Guzzle-Redirect-Status-History')[0]; // retrieve Redirect HTTP Status history
// Add the initial URI requested to the (beginning of) URI history
array_unshift($redirectUriHistory, $initialRequest);
// Add the final HTTP status code to the end of HTTP response history
array_push($redirectCodeHistory, $response->getStatusCode());
// (Optional) Combine the items of each array into a single result set
$fullRedirectReport = [];
foreach ($redirectUriHistory as $key => $value) {
$fullRedirectReport[$key] = ['location' => $value, 'code' => $redirectCodeHistory[$key]];
}
echo json_encode($fullRedirectReport);