معالج cURL في Guzzle: التقاط ترويسات CONNECT الخاصة بالوكيل

قد يتلقى طلب HTTPS عبر وكيل HTTP استجابةً واحدة تقبل CONNECT، ثم استجابة لاحقة من الموقع داخل ذلك النفق. لإعداد المسار الأولي، راجع خيار الوكيل لكل طلب في Guzzle. ليس من الضروري أن يوجد ترويس موجود في الاستجابة الأولى في كائن الاستجابة النهائي.

لإعادة الإنتاج باستخدام نقطة نهاية HTTP تختارها بنفسك، خذ مرشحًا من قائمة وكلاء HTTP وتأكد من أنه يقبل نفق HTTPS. في مسار معالج cURL في Guzzle 7.10، احتفظ بكل استدعاء رجعي للترويسات ككتلة منفصلة:

$blocks = [];
$client = new \GuzzleHttp\Client([
    'handler' => \GuzzleHttp\HandlerStack::create(
        new \GuzzleHttp\Handler\CurlHandler()
    ),
]);

$response = $client->get('https://www.example.com/', [
    'proxy' => 'http://proxy.example:8080',
    'curl' => [CURLOPT_SUPPRESS_CONNECT_HEADERS => false],
    'on_headers' => function (
        \Psr\Http\Message\ResponseInterface $part
    ) use (&$blocks) {
        $blocks[] = [
            'status' => $part->getStatusCode(),
            'reason' => $part->getReasonPhrase(),
            'headers' => $part->getHeaders(),
        ];
    },
]);

يجب أن يوفّر امتداد cURL الخيار CURLOPT_SUPPRESS_CONNECT_HEADERS، وهو خيار أُضيف في libcurl 7.54.0. تعيينه إلى false يسمح لترويسات CONNECT بالوصول إلى الاستدعاء الرجعي للترويسات في cURL. يبني معالج Guzzle 7.10 استجابةً لكل كتلة ترويسات مكتملة ويستدعي on_headers عند تلك الحدود.

أبقِ الكتل بالترتيب. قد تنتج تحديات المصادقة وعمليات إعادة التوجيه والردود المعلوماتية كتلًا إضافية؛ لا تسطّح كل القيم في مصفوفة واحدة ولا تصنّف استجابةً لمجرد أن حالتها 200.

تمثّل الاستجابة المُعادة استجابة الطلب المكتمل، بينما يحتفظ blocks بالملاحظات التي جمعتها الاستدعاءات الرجعية. إذا فشل إعداد النفق أو TLS، فتعامل مع استثناء النقل المطروح في التطبيق المستدعي؛ فقد لا توجد استجابة نهائية من الموقع.

يرتبط هذا السلوك بمعالج cURL المذكور. لا يُشترط أن يوفّر معالج مخصص أو معالج تدفق نفس الاستدعاءات الرجعية لمصافحة الوكيل. تعامل مع ترويسات الوكيل الملتقطة كبيانات تشخيصية وتجنّب الاحتفاظ بقيم مرتبطة بالحساب دون داعٍ.