Функциите за запис в PHP cURL трябва да връщат броя обработени байтове

Спазвайте договора за броя байтове при консумиране на части от отговора през прокси и различавайте локален неуспех при запис от неуспешна връзка с прокси.

Проксито доставя данни. Вашата функция за запис връща грешна стойност. Тогава libcurl прекратява и околният код съобщава поредния „неуспех при изтегляне през прокси“.

Функцията трябва да съобщи колко получени байта всъщност е обработила. Връщането на различен брой означава неуспех. За умишлено блокиращ приемник за запис фрагментът може да изглежда така:

curl_setopt($handle, CURLOPT_PROXY, 'http://proxy.example:8080');
curl_setopt($handle, CURLOPT_WRITEFUNCTION,
    function ($handle, $chunk) use ($sink) {
        $written = fwrite($sink, $chunk);
        return $written === false ? 0 : $written;
    }
);

Това предполага, че съществуващото приложение притежава манипулатора и приемника. Неуспешен или кратък запис прекратява, вместо тихо да твърди, че цялата част е запазена. Неблокиращият приемник се нуждае от подходящ дизайн за буфериране и пауза/възобновяване; малкият фрагмент не предоставя такъв.

Бройте байтове, а не показвани знаци. Данните може да са двоични или част от многобайтова текстова последователност. Едно извикване не е задължително един ред, JSON документ или съобщение от услугата.

Инкременталният анализ се нуждае от собствено състояние между извикванията. Обратно, натрупването на всяка част до завършване може да е правилно за малък ограничен отговор, но не е политика за памет за голям или безкраен поток.

Пазете резултата от трансфера и доказателството за неуспех на функцията. Локална дискова грешка или прекъсване на анализатора може да настъпи след установяване на валиден маршрут през прокси. Ако възнамерявате да спрете след префикс, отбележете това умишлено спиране отделно. Смяната на адреса на проксито не може да поправи приемник, който е спрял да приема данни.

Подобни статии