Ei. Guzzle võib kasutada päringute saatmiseks mis tahes HTTP-käsitlejat. See tähendab, et Guzzle saab kasutada koos cURL-i, PHP voogedastuse pakendiga, sokkidega ja mitteblokeerivate raamatukogudega. nagu React. Teil on vaja lihtsalt konfigureerida HTTP-käsitleja kasutama teistsugust päringute saatmise meetodit.
Märkus
Guzzle on ajalooliselt kasutanud HTTP päringute saatmiseks ainult cURL-i. cURL on hämmastav HTTP-klient (vaieldamatult parim) ja Guzzle jätkab selle kasutamist. seda vaikimisi, kui see on saadaval. See on haruldane, kuid mõned arendajad ei ole ei ole cURL-i oma süsteemi paigaldatud või ei ole neil versioonispetsiifilisi probleeme. Lubades vahetatavaid HTTP-käsitlejaid, on Guzzle nüüd palju paremini kohandatav. ja võimeline kohanema, et see vastaks rohkemate arendajate vajadustele.
Jah. Võite kasutada requestAsync
, sendAsync
, getAsync
,
headAsync
, putAsync
, postAsync
, deleteAsync
ja patchAsync
meetodid kliendi asünkroonse päringu saatmiseks. Klient tagastab
GuzzleHttp\Promise\PromiseInterface
objekti. Saate then
funktsioone lubadusest.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$promise->then(function ($response) {
echo 'Got a response! ' . $response->getStatusCode();
});
Saate sundida asünkroonse vastuse lõpuleviimist, kasutades tagastatud lubaduse wait()
meetodit.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$response = $promise->wait();
cURL pakub väga palju kohandatavaid võimalusi. Kuigi Guzzle normaliseerib paljud neist valikutest erinevate käitlejate vahel, on mõnikord on vaja määrata kohandatud cURLi valikuid. Seda saab teha edastades assotsiatiivse massiivi cURL-i seadetest curl võtmes curl päringule.
Oletame näiteks, et teil on vaja kohandada kliendiga kasutatavat väljaminevat võrguliidest.
$client->request('GET', '/', [
'curl' => [
CURLOPT_INTERFACE => 'xxx.xxx.xxx.xxx'
]
]);
Kui kasutate asünkroonseid taotlusi cURL multi handleriga ja soovite seda sättida,
saab lisavõimalusi määrata assotsiatiivse massiivi kujul failis
options võtmes CurlMultiHandler
konstruktoris.
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,
]
]))]);
Saate edastada kohandatud voogkonteksti valikuid kasutades stream_context võtit taotlusvaliku juures. stream_context massiiv on assotsiatiivne massiiv, kus iga võti on PHP transport ja iga väärtus on assotsiatiivne transpordivõimaluste massiivi.
Oletame näiteks, et teil on vaja kohandada kliendiga kasutatavat väljaminevat võrguliidest ja lubada isesigneeritud sertifikaate.
$client->request('GET', '/', [
'stream' => true,
'stream_context' => [
'ssl' => [
'allow_self_signed' => true
],
'socket' => [
'bindto' => 'xxx.xxx.xxx.xxx'
]
]
]);
Peate määrama plaadil oleva tee CA-paketi juurde, mida Guzzle kasutab võrdlussertifikaadi kontrollimiseks. Vt verify.
Maximum function nesting level of '100' reached, aborting
See viga võib tekkida, kui teil on paigaldatud XDebug laiendus ja te täidate palju päringuid tagasikutsetes. See veateade tuleb konkreetselt XDebug laiendusest. PHP-l endal ei ole funktsiooni pesitsemise piirangut. Muutke seda seadistust oma php.ini's, et seda piirangut suurendada:
xdebug.max_nesting_level = 1000
See võib juhtuda mitmel põhjusel, kuid kui sa saadad PUT, POST või
PATCH päringuid Expect: 100-Continue
päisega, siis server, mis ei ole
toetab seda päistekirja, tagastab vastuse 417. Seda saab vältida järgmiselt
määrates expect
päringuvõimaluse false
:
$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]);
Saate lubada ümberjuhitud URIde ja staatuskoodide jälgimist funktsiooni
track_redirects valikuga. Iga ümbersuunatud URI ja staatuskood salvestatakse kataloogi
X-Guzzle-Redirect-History
ja X-Guzzle-Redirect-Status-History
.
päises vastavalt.
Esialgse taotluse URI ja lõplik staatuskood jäetakse tulemustest välja. Seda silmas pidades peaks teil olema võimalik hõlpsasti jälgida taotluse täielikku ümbersuunamise teed.
Oletame näiteks, et teil on vaja jälgida ümbersuunamisi ja esitada mõlemad tulemused koos ühes aruandes:
// 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);