Funcțiile de scriere din PHP cURL trebuie să returneze numărul de octeți tratați

Respectați contractul privind numărul de octeți atunci când consumați fragmente din răspunsul proxy și distingeți o eroare locală de scriere de o conexiune proxy eșuată.

Proxy-ul livrează date. Funcția dumneavoastră de scriere returnează valoarea greșită. Apoi libcurl abandonează, iar codul din jur raportează încă o „eșuare a descărcării prin proxy”.

Funcția trebuie să raporteze câți octeți primiți a tratat efectiv. Returnarea unui număr diferit semnalează eșec. Pentru o destinație de scriere deliberat blocantă, un fragment poate arăta astfel:

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

Aceasta presupune că aplicația existentă deține handle-ul și destinația de scriere. O scriere eșuată sau scurtă abandonează în loc să afirme în tăcere că întregul fragment a fost salvat. O destinație neblocantă necesită un proiect adecvat de tamponare și pauză/reluare; fragmentul mic nu oferă unul.

Numărați octeți, nu caractere afișate. Datele pot fi binare sau parte dintr-o secvență de text multi-octet. Un apel nu este neapărat o linie, un document JSON sau un mesaj de la serviciu.

Analiza incrementală are nevoie de propria stare între apeluri. Invers, acumularea fiecărui fragment până la finalizare poate fi corectă pentru un răspuns mic și limitat, dar nu este o politică de memorie pentru un flux mare sau nesfârșit.

Păstrați rezultatul transferului și dovezile eșecului apelului. O eroare locală de disc sau o oprire a parserului poate apărea după stabilirea unei rute proxy valide. Dacă intenționați să vă opriți după un prefix, marcați separat acea oprire deliberată a apelului. Înlocuirea adresei proxy nu poate repara o destinație care a încetat să accepte date.

Articole similare