libcurl ના પ્રોક્સી હેડરોને વેબસાઇટ હેડરોથી અલગ કરો
libcurl ને અલગ પ્રોક્સી અને ગંતવ્ય હેડર યાદીઓ આપો, સાથે સાથે સ્વીકારો કે પ્લેઇનટેક્સ્ટ ફોરવર્ડિંગની દૃશ્યતાની સીમા અલગ છે.
હાલના libcurl હેન્ડલ માટે, ગંતવ્ય અને પ્રોક્સી હેડર યાદીઓ સ્પષ્ટ રીતે અલગ કરો:
curl_easy_setopt(handle, CURLOPT_HEADEROPT, (long)CURLHEADER_SEPARATE);
curl_easy_setopt(handle, CURLOPT_PROXYHEADER, proxy_headers);
curl_easy_setopt(handle, CURLOPT_HTTPHEADER, origin_headers); ગોઠવેલું હેન્ડલ અને માન્ય યાદીઓ ટ્રાન્સફર દરમિયાન જીવંત રાખો. CURLHEADER_SEPARATE CONNECT પર વપરાતા હેડરોને ગંતવ્ય વિનંતી માટે વપરાતા હેડરોથી અલગ પાડે છે. જૂના એકીકૃત-નીતિના ઉદાહરણો સામાન્ય યાદીને બંને વિનિમયોમાં મૂકી શકે છે.
| વિનંતીનો માર્ગ | અલગ યાદીઓનો અર્થ |
|---|---|
| સામાન્ય CONNECT ટનલની અંદર HTTPS | પ્રોક્સી વિનિમય પહેલા આવે છે; પછી ગંતવ્ય HTTP હેડરો ગંતવ્ય TLS ની અંદર અનુસરે છે. |
| સામાન્ય HTTP ફોરવર્ડિંગ | પ્રોક્સી ગંતવ્ય હેડરો વાંચી શકે છે, અને libcurl એક ફોરવર્ડ કરેલી વિનંતી પર બંને લાગુ યાદીઓ વાપરી શકે છે. |
ફક્ત-પ્રોક્સી રૂટિંગ માર્કર પ્રોક્સી વિનિમય પર આવે છે. પ્લેઇનટેક્સ્ટ ફોરવર્ડિંગમાં, મનસ્વી કસ્ટમ ફીલ્ડ મૂળ સુધી પહોંચી શકે છે જ્યાં સુધી ફોરવર્ડિંગ ગોઠવણી તેને સંભાળે નહીં; વિકલ્પનું નામ ગોપનીયતાની બાંયધરી નથી.
પ્રમાણીકરણ માટે સમર્થિત ક્રેડેન્શિયલ વિકલ્પો વાપરો. ઓપરેટર-વ્યાખ્યાયિત મેટાડેટા માટે, કયો હોપ તેનો ઉપયોગ કરે છે અને સામાન્ય ફીલ્ડમાં પાસવર્ડ મૂકવાને બદલે તેને ફોરવર્ડ કરી શકાય છે કે નહીં તે નક્કી કરો.
જ્યારે માર્કર ખૂટે અથવા લીક થતું લાગે, ત્યારે તેને ધરાવતી વાસ્તવિક વિનંતી ઓળખો. ઘણા વિનિમયો દર્શાવતું હેડર કૉલબેક યોગ્ય રીતે અલગ કરેલી યાદીઓને મિશ્ર દેખાવા દઈ શકે છે.