curl -N किसी प्रॉक्सी को बफ़रिंग रोकने के लिए नहीं कह सकता

curl -N, या --no-buffer, curl के आउटपुट-स्ट्रीम बफ़रिंग को बंद कर देता है। प्रॉक्सी या सर्वर की बफ़रिंग नीति बदले बिना विलंबित आउटपुट का निदान करने में यह मदद कर सकता है।

curl --proxy http://proxy.example:8080 --noproxy '' --no-buffer --max-time 30 https://example.com/stream

किसी सार्वजनिक प्रॉक्सी से तुलना के लिए HTTP प्रॉक्सी सूची से कोई HTTP एंडपॉइंट चुनें। अपना वास्तविक स्ट्रीम URL इस्तेमाल करें और इच्छित सीमा चुनें। खाली बायपास सूची इस तुलना को चुने गए प्रॉक्सी मार्ग पर रखती है।

आगमन, डिकोडिंग और प्रदर्शन

सर्वर क्रमिक बाइट बना सकता है, मध्यस्थ उन्हें इकट्ठा कर सकता है, क्लाइंट लाइब्रेरी पूरा बॉडी पढ़ सकती है, और ब्राउज़र रेंडरिंग टाल सकता है। जहाँ आप मार्ग नियंत्रित करते हैं वहाँ पहले उपयोगी बाइट और उसके बाद की प्रगति की तुलना करें। पेंट समय और सर्वर की कुल अवधि यह नहीं बताते कि बॉडी कब पहुँचती है।

Guzzle में स्ट्रीमिंग और बॉडी खपत अलग से जाँचें। कम्प्रेशन एक डिकोडिंग चरण जोड़ता है। डिकोड किया गया आउटपुट कब दिखता है, इसका बदलना अपने आप यह सिद्ध नहीं करता कि प्रॉक्सी ही बफ़रिंग घटक है।

मध्यस्थ क्या देखता है

एक अपारदर्शी CONNECT प्रॉक्सी आंतरिक HTTPS प्रतिक्रियाओं को सामान्य HTTP की तरह पार्स नहीं कर सकता। अधिकृत TLS निरीक्षण सेवा की दृश्यता अलग होती है, इसलिए अकेला HTTPS यह सिद्ध नहीं करता कि निरीक्षण नहीं हो रहा है।

प्रतीक्षा चरण पहचानने के बाद उस घटक द्वारा समर्थित स्ट्रीमिंग नियंत्रण इस्तेमाल करें। रिवर्स-प्रॉक्सी निर्देश अपने आप फ़ॉरवर्ड प्रॉक्सी पर लागू नहीं होते; curl का आउटपुट फ़्लैग केवल अपने हिस्से का मार्ग बदलता है।