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

આ ધારે છે કે હાલની એપ્લિકેશન handle અને લેખન સિંક ધરાવે છે. નિષ્ફળ અથવા ટૂંકું લેખન આખો ટુકડો સાચવાયો હોવાનો શાંત રીતે દાવો કરવાને બદલે અટકી જાય છે. બિન-બ્લોકિંગ સિંકને યોગ્ય બફરિંગ અને વિરામ/ફરી શરૂ કરવાની રચના જોઈએ; નાનો ટુકડો એ પ્રદાન કરતો નથી.

બાઇટ ગણો, દર્શાવેલા અક્ષરો નહીં. ડેટા બાઇનરી અથવા બહુ-બાઇટ ટેક્સ્ટ ક્રમનો ભાગ હોઈ શકે. એક કૉલબૅક જરૂરી નથી કે એક લીટી, એક JSON દસ્તાવેજ અથવા સેવા તરફથી એક સંદેશ હોય.

ઇન્ક્રિમેન્ટલ પાર્સિંગને કૉલબૅક વચ્ચે પોતાની સ્થિતિ જોઈએ. તેનાથી વિપરીત, પૂર્ણ થાય ત્યાં સુધી દરેક ટુકડો એકઠો કરવો નાના મર્યાદિત પ્રતિસાદ માટે યોગ્ય હોઈ શકે, પણ મોટા કે અનંત સ્ટ્રીમ માટે મેમરી નીતિ નથી.

ટ્રાન્સફરનું પરિણામ અને કૉલબૅક નિષ્ફળતાના પુરાવા રાખો. માન્ય પ્રોક્સી માર્ગ સ્થપાયા પછી સ્થાનિક ડિસ્ક ભૂલ અથવા પાર્સર અટકી શકે છે. જો તમે પ્રીફિક્સ પછી થોભવા માંગો છો, તો એ ઇરાદાપૂર્વકના કૉલબૅક સ્ટોપને અલગથી ચિહ્નિત કરો. પ્રોક્સી સરનામું બદલવાથી ડેટા સ્વીકારવાનું બંધ કરેલ સિંક સુધારી શકાતો નથી.