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 और त्रुटियों को अलग-अलग संभालें, और प्रसंस्करण समाप्त या रद्द होने पर बॉडी बंद करें।