Nem. A Guzzle bármilyen HTTP kezelőt használhat a kérések küldésére. Ez azt jelenti, hogy a Guzzle használható a cURL-lel, a PHP stream wrapperével, a socketekkel és a nem blokkoló könyvtárakkal. mint például a React. Csak egy HTTP kezelőt kell konfigurálnia. hogy más módszert használjon a kérések küldésére.
Megjegyzés:
A Guzzle történelmileg csak a cURL-t használta a HTTP-kérések küldésére. egy csodálatos HTTP kliens (vitathatatlanul a legjobb), és a Guzzle továbbra is a cURLUR-t fogja használni. alapértelmezés szerint használni fogja, ha elérhető lesz. Ritka, de egyes fejlesztők nem a cURL telepítve van a rendszerükön, vagy verzió-specifikus problémákba ütköznek. A cserélhető HTTP kezelők engedélyezésével a Guzzle sokkal jobban testreszabhatóvá vált. és képes alkalmazkodni több fejlesztő igényeihez.
Igen. Használhatja a requestAsync, sendAsync, getAsync parancsokat,
headAsync, putAsync, postAsync, deleteAsync, és patchAsync.
metódusok egy kliens aszinkron kérés küldésére. Az ügyfél egy
GuzzleHttp\Promise\PromiseInterface objektumot. Láncolhatjuk a then
függvényeket az ígéretből.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$promise->then(function ($response) {
echo 'Got a response! ' . $response->getStatusCode();
});
Az aszinkron válasz befejezését a visszaadott ígéret wait() metódusával kényszerítheti ki.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$response = $promise->wait();
A cURL rengeteg testreszabható opciót kínál. Míg a Guzzle sok ilyen opciót normalizál a különböző kezelők között, addig a vannak olyan esetek, amikor egyéni cURL opciókat kell beállítanunk. Ez megvalósítható a cURL-beállítások asszociatív tömbjének átadásával a curl kulcsban egy request.
Tegyük fel például, hogy testre kell szabni az ügyféllel használt kimenő hálózati interfészt.
$client->request('GET', '/', [
'curl' => [
CURLOPT_INTERFACE => 'xxx.xxx.xxx.xxx'
]
]);
Ha aszinkron kéréseket használsz a cURL multi handlerrel, és szeretnéd finomítani,
további opciókat adhatunk meg asszociatív tömbként a
options kulcsában a CurlMultiHandler konstruktorban.
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,
]
]))]);
Átadhat egyéni folyam-kontextus beállításokat a kérési opció stream_context kulcsának használatával. Az stream_context tömb egy asszociatív tömb, ahol minden kulcs egy PHP-transzport, és minden érték a szállítási lehetőségek asszociatív tömbje.
Tegyük fel például, hogy testre kell szabni az ügyféllel használt kimenő hálózati interfészt, és engedélyezni kell az önaláírt tanúsítványokat.
$client->request('GET', '/', [
'stream' => true,
'stream_context' => [
'ssl' => [
'allow_self_signed' => true
],
'socket' => [
'bindto' => 'xxx.xxx.xxx.xxx'
]
]
]);
Meg kell adnia a Guzzle által a társtanúsítvány ellenőrzéséhez használt hitelesítésszolgáltatói csomag lemezen található elérési útvonalát. Lásd verify.
Maximum function nesting level of '100' reached, aborting
Ez a hiba akkor fordulhat elő, ha telepítve van az XDebug kiterjesztés és a sok kérést hajt végre a visszahívásokban. Ez a hibaüzenet a következő kifejezetten az XDebug bővítménytől származik. Maga a PHP nem rendelkezik olyan függvénnyel beágyazási korlátja. Módosítsa ezt a beállítást a php.ini fájlban a limit növeléséhez:
xdebug.max_nesting_level = 1000
Ez több okból is előfordulhat, de ha PUT, POST vagy
PATCH kéréseket Expect: 100-Continue fejléccel, egy olyan kiszolgáló, amelyik nem
nem támogatja ezt a fejlécet, 417-es választ fog visszaküldeni. Ezt megkerülheti a következő módon
a expect kérési opciót false értékre állítjuk:
$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]);
Az átirányított URI-k és státuszkódok nyomon követését a
track_redirects opció segítségével. Minden átirányított URI és státuszkód az alábbiakban kerül tárolásra
X-Guzzle-Redirect-History és a X-Guzzle-Redirect-Status-History között.
fejlécet.
A kezdeti kérés URI-je és a végső státuszkód nem kerül ki az eredményekből. Ezt szem előtt tartva könnyen nyomon követheti a kérés teljes átirányítási útvonalát.
Tegyük fel például, hogy nyomon kell követnie az átirányításokat, és mindkét eredményt egyetlen jelentésben kell megadnia:
// 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);