PHP cURL પ્રોક્સી હેડર: CONNECT વિરુદ્ધ ગંતવ્ય પ્રતિસાદ

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

$headerLines = [];
curl_setopt($handle, CURLOPT_HEADERFUNCTION,
    function ($handle, $line) use (&$headerLines) {
        $headerLines[] = $line;
        return strlen($line);
    }
);

આ કૉલબેક કાચી લાઇન ક્રમ જાળવે છે અને સ્વીકારેલા બાઇટની સંખ્યા પરત કરે છે. તે પૂર્ણ લાઇનો મેળવે છે; પરંતુ તે હજી તેમને પ્રતિસાદમાં જૂથબદ્ધ કરતું નથી કે અંતિમ વેબસાઇટના હેડર પસંદ કરતું નથી.

ક્રમને બ્લોક તરીકે અર્થઘટન કરો

HTTP સ્થિતિ લાઇન પ્રતિસાદ બ્લોક શરૂ કરે છે, અને ખાલી લાઇન તેના હેડર સમાપ્ત કરે છે. અંતિમ ગંતવ્ય પ્રતિસાદ પસંદ કરતા પહેલાં તે સીમાઓ જાળવો. મધ્યવર્તી પ્રમાણીકરણ પ્રયાસો અને રીડાયરેક્ટ દરેક બ્લોક ઉમેરી શકે છે.

ટ્રેલર પછીથી કૉલબેક દ્વારા આવી શકે છે. દરેક પછીના ફીલ્ડને પ્રથમ પ્રતિસાદ સાથે જોડવાને બદલે તેમને પ્રારંભિક હેડરથી અલગ પાડવા પૂરતી પાર્સર સ્થિતિ રાખો.

ટનલનો પુરાવો રાખો અથવા દબાવો

HTTPS ટનલની CONNECT સ્થિતિ માટે CURLINFO_HTTP_CONNECTCODE અલગથી વાંચો. સ્વીકારાયેલી ટનલ સફળ વેબસાઇટ પ્રતિસાદ સાબિત કરતી નથી.

જો સંગ્રાહકને CONNECT હેડરની જરૂર ન હોય, તો CURLOPT_SUPPRESS_CONNECT_HEADERS રૂપરેખાંકિત હેડર આઉટપુટ અને કૉલબેક માર્ગોમાં તેમની ડિલિવરી નિયંત્રિત કરે છે. જોડાયેલ libcurl અને PHP બિલ્ડમાં સમર્થન તપાસો. દબાવવાથી સંગ્રહ સરળ બને છે, પરંતુ નિદાનમાં મદદ કરી શકે તેવો હેડર-સ્તરીય ટનલ પુરાવો દૂર થાય છે.

સ્થિર ઓફસેટ દ્વારા અથવા HTML ટૅગ શોધીને મુખ્ય ભાગ પુનઃપ્રાપ્ત કરશો નહીં. હેડરના કદ બદલાય છે, મધ્યવર્તી પ્રતિસાદ અલગ હોય છે, અને મુખ્ય ભાગ બાઇનરી કે ખાલી હોઈ શકે છે. જૂનો આવૃત્તિ-વિશિષ્ટ બગ રિપોર્ટ અનુમાનિત ઓફસેટને ન્યાયી ઠેરવતો નથી.

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