Чаму паток цела Guzzle усё яшчэ можа буферавацца

Інтэрфейс цела, дастаўка транспартам і ваш уласны парсер могуць буфераваць незалежна. Выкарыстоўвайце stream явна і захоўвайце спажыванне паступовым.

getBody() вяртае інтэрфейс патоку, нават калі Guzzle ужо спампаваў адказ. Каб запытаць паступовую сеткавую дастаўку праз прамы проксі, усталюйце stream у запыце:

$response = $client->request('GET', 'https://example.com/stream', [
    'proxy' => 'http://proxy.example:8080',
    'stream' => true,
    'read_timeout' => 10,
]);
$body = $response->getBody();

Гэта выкарыстоўвае існуючы кліент; для публічнай HTTP-канчатковай кропкі выберыце адрас са спісу HTTP-проксі і заменіце прыкладны URL проксі. Падтрымка патоку залежыць ад яго апрацоўшчыка; адзін інтэрфейс патоку не можа сказаць, ці апрацоўшчык дастаўляў цела паступова.

Пасля прыходу адказу працягвайце чытаць абмежаваныя часткі. Пераўтварэнне $body у радок зноў збірае ўсё цела. Парсер радкоў таксама можа выглядаць завіслым у чаканні новага радка, нават калі сеткавыя байты ўжо прыйшлі. Гэта затрымкі спажывання, таму змена проксі іх не прыбярэ.

read_timeout абмяжоўвае асобныя чаканні чытання ў межах падтрымоўванай рэалізацыі патоку. Ён не дае бясконцаму патоку агульны час жыцця ў дзесяць секунд. Апрацоўвайце тайм-аўт, EOF і памылкі асобна, і закрывайце цела, калі апрацоўка скончваецца або скасоўваецца.

Падобныя артыкулы