Кантэкст HTTP-проксі ў PHP не перанастройвае сыры TCP-паток
Адрознівайце опцыі проксі HTTP-абгорткі PHP ад працы пратакола, патрэбнай для TCP-злучэння stream_socket_client.
Опцыя проксі ў кантэксце HTTP належыць HTTP-абгортцы патоку PHP. Сырое TCP-злучэнне, створанае stream_socket_client, не робіцца кліентам HTTP-проксі толькі таму, што гэтая опцыя існуе ў аб'екце кантэксту.
Калі код злучаецца непасрэдна з адрасам прызначэння, ён адкрывае гэты маршрут TCP. Калі ж ён злучаецца з адрасам проксі, наступныя байты ўсё яшчэ павінны рэалізоўваць пратакол проксі.
Для HTTP CONNECT гэта значыць сапраўдны хост і порт прызначэння, любую патрэбную аўтэнтыфікацыю проксі, поўны разбор адказу і прыняцце да пачатку пратаколу прызначэння. Адзін выклік fread, які шукае фразу поспеху, не з'яўляецца поўным злучальнікам. TCP можа падзяліць адказ паміж чытаннямі або вярнуць дадатковыя байты, якія трэба захаваць.
Для прызначэння HTTPS пратакол TLS мусіць пачацца праз усталяваны тунель і праверыць ідэнтычнасць прызначэння. Імя хоста проксі не з'яўляецца ідэнтычнасцю сертыфіката сайта.
Выкарыстоўвайце кліент або злучальнік з дакументаванай падтрымкай патрэбнага пратаколу проксі, калі задача проста атрымаць URL. Налады HTTP і SOCKS у PHP cURL даюць адзін падтрыманы шлях атрымання URL. Сыры паток карысны, калі праграма бярэ на сябе гэтую працу пратаколу ніжняга ўзроўню; ён не павінен моўчкі пераймаць здагадкі з непаветанага прыкладу HTTP-абгорткі.