Nej. Guzzle kan bruge enhver HTTP-handler til at sende anmodninger. Det betyder, at Guzzle kan bruges sammen med cURL, PHP's stream wrapper, sockets og ikke-blockerende biblioteker som React. Du skal blot konfigurere en HTTP-handler til at bruge en anden metode til at sende anmodninger.
Bemærk
Guzzle har historisk set kun brugt cURL til at sende HTTP-forespørgsler. cURL er en fantastisk HTTP-klient (vel nok den bedste), og Guzzle vil fortsat bruge den som standard, når den er tilgængelig. Det er sjældent, men nogle udviklere vil ikke har cURL installeret på deres systemer eller løber ind i versionsspecifikke problemer. Ved at tillade swappable HTTP-handlers er Guzzle nu meget mere tilpasningsdygtig og i stand til at tilpasse sig til at passe til flere udvikleres behov.
Ja. Du kan bruge requestAsync, sendAsync, getAsync,
headAsync, putAsync, postAsync, deleteAsync, og patchAsync
metoder i en klient til at sende en asynkron anmodning. Klienten returnerer en
GuzzleHttp\Promise\PromiseInterface objekt tilbage. Du kan kæde then
funktioner fra løftet.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$promise->then(function ($response) {
echo 'Got a response! ' . $response->getStatusCode();
});
Du kan tvinge et asynkront svar til at blive afsluttet ved hjælp af wait() metoden for det returnerede løfte.
$promise = $client->requestAsync('GET', 'http://httpbin.org/get');
$response = $promise->wait();
cURL tilbyder et stort antal indstillingsmuligheder. Mens Guzzle normaliserer mange af disse muligheder på tværs af forskellige handlers, er der er der tidspunkter, hvor du har brug for at indstille brugerdefinerede cURL-optioner. Dette kan gøres ved at sende et associerende array af cURL-indstillinger i curl-nøglen i en anmodning.
Lad os f.eks. sige, at du har brug for at tilpasse den udgående netværksgrænseflade, der bruges med en klient.
$client->request('GET', '/', [
'curl' => [
CURLOPT_INTERFACE => 'xxx.xxx.xxx.xxx'
]
]);
Hvis du bruger asynkrone anmodninger med cURL multihandler og ønsker at justere den,
kan du angive yderligere indstillinger som et associerende array i
options nøgle i CurlMultiHandler konstruktøren.
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,
]
]))]);
Du kan sende brugerdefinerede stream context options ved hjælp af stream_context-nøglen i anmodningsindstillingen. Den stream_context array er et associerende array, hvor hver nøgle er en PHP-transport, og hver værdi er et associativt array af transportmuligheder.
Lad os f.eks. sige, at du har brug for at tilpasse den udgående netværksgrænseflade, der bruges med en klient, og tillade selvsignerede certifikater.
$client->request('GET', '/', [
'stream' => true,
'stream_context' => [
'ssl' => [
'allow_self_signed' => true
],
'socket' => [
'bindto' => 'xxx.xxx.xxx.xxx'
]
]
]);
Du skal angive stien på disken til det CA-bundle, som Guzzle bruger til at verificere peer-certifikatet. Se verify.
Maximum function nesting level of '100' reached, aborting
Du kan løbe ind i denne fejl, hvis du har XDebug-udvidelsen installeret og du udfører mange anmodninger i callbacks. Denne fejlmeddelelse kommer specifikt fra XDebug-udvidelsen. PHP selv har ikke en funktion nesting-grænse. Ændr denne indstilling i din php.ini for at øge grænsen:
xdebug.max_nesting_level = 1000
Dette kan ske af flere årsager, men hvis du sender PUT, POST eller
PATCH-forespørgsler med en Expect: 100-Continue header, kan en server, der ikke har
understøtter denne header, vil returnere et 417-svar. Du kan omgå dette ved at
indstille expect request option til 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]);
Du kan aktivere sporing af omdirigerede URI'er og statuskoder via
track_redirects indstillingen. Hver omdirigeret URI og statuskode vil blive gemt i
X-Guzzle-Redirect-History og X-Guzzle-Redirect-Status-History
henholdsvis header.
Den oprindelige anmodnings URI og den endelige statuskode vil blive udelukket fra resultaterne. Med dette i tankerne bør du nemt kunne spore en anmodnings fulde omdirigeringssti.
Lad os f.eks. sige, at du har brug for at spore omdirigeringer og give begge resultater sammen i en enkelt rapport:
// 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);