Callbacks zapisu PHP cURL muszą zwracać liczbę obsłużonych bajtów

Przestrzegaj kontraktu liczby bajtów podczas konsumowania fragmentów odpowiedzi proxy i odróżniaj lokalny błąd zapisu od nieudanego połączenia z proxy.

Proxy dostarcza dane. Twoje callback zapisu zwraca niewłaściwą wartość. Wtedy libcurl przerywa, a otaczający kod zgłasza kolejny „błąd pobierania przez proxy”.

Callback musi zgłosić, ile odebranych bajtów faktycznie obsłużył. Zwrócenie innej liczby sygnalizuje błąd. Dla celowo blokującego ujścia zapisu fragment może wyglądać tak:

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;
    }
);

Zakłada to, że istniejąca aplikacja posiada uchwyt i ujście zapisu. Nieudany lub krótki zapis przerywa, zamiast po cichu twierdzić, że cały fragment został zapisany. Nieblokujące ujście wymaga odpowiedniego projektu buforowania oraz wstrzymania/wznowienia; mały fragment go nie zapewnia.

Licz bajty, a nie wyświetlane znaki. Dane mogą być binarne lub częścią wielobajtowej sekwencji tekstowej. Jedno wywołanie nie musi być jedną linią, jednym dokumentem JSON ani jedną wiadomością z usługi.

Parsowanie przyrostowe wymaga własnego stanu między wywołaniami. Odwrotnie, gromadzenie każdego fragmentu do ukończenia może być poprawne dla małej ograniczonej odpowiedzi, ale nie jest polityką pamięci dla dużego lub niekończącego się strumienia.

Zachowaj wynik transferu i dowody błędu callbacku. Lokalny błąd dysku lub przerwanie parsera może wystąpić po ustanowieniu prawidłowej trasy proxy. Jeśli zamierzasz zatrzymać się po prefiksie, oznacz to celowe zatrzymanie callbacku osobno. Zmiana adresu proxy nie naprawi ujścia, które przestało przyjmować dane.

Powiązane artykuły