HTTP અપલોડ વિરામ અને Expect: 100-continue

Expect: 100-continue ની આપલે ઓળખો અને તેના ટૂંકા નિર્ણય-બિંદુને ડેટા ટ્રાન્સફર દરમિયાન અટકેલા અપલોડથી અલગ પાડો.

કનેક્શન ખૂલે છે. વિનંતીના હેડર જાય છે. ફાઇલ હલતી નથી એમ લાગે છે. એક સમજૂતી એ છે કે ક્લાયન્ટ પોતાનું બોડી મોકલતા પહેલાં Expect: 100-continue ના જવાબની રાહ જુએ છે.

આ પ્રક્રિયા પ્રાપ્તકર્તાને સંભવિત મોટું અપલોડ મોકલાય તે પહેલાં હેડરના આધારે વિનંતી નકારવાની છૂટ આપે છે. સામાન્ય સફળ ક્રમ આ છે:

request headers → 100 Continue → request body → final response

100 માહિતીપ્રદ છે: તે ક્લાયન્ટને આગળ વધવા દે છે, પરંતુ ફાઇલ સંગ્રહાઈ છે કે એપ્લિકેશનની કામગીરી સફળ થઈ છે એમ નથી કહેતું. Git push દ્વારા HTTP 417 પાછું આવવું એ અપેક્ષા નિષ્ફળતાનો એક નક્કર કિસ્સો છે.

ક્લાયન્ટને કયો જવાબ મળ્યો તે શોધો

નિરીક્ષણતપાસવાનો અર્થ
100 Continueક્લાયન્ટ બોડી સાથે આગળ વધી શકે છે
બોડી પહેલાં અંતિમ નકારકામગીરી હેડર તબક્કે નકારાઈ
કોઈ અપેક્ષિત મધ્યવર્તી જવાબ નથીક્લાયન્ટની રાહ જોવાની નીતિ અને તે માર્ગ પરની સંભાળ

curl expect-continue માટે અલગ રાહ જોવાનું સેટિંગ આપે છે. જો તે libcurl રાહ અપેક્ષિત જવાબ વિના પૂરી થાય, તો તે બોડી તો મોકલે જ છે; પૂરી થવું આપોઆપ આખા ટ્રાન્સફરની નિષ્ફળતા નથી. આ સેટિંગ સંપૂર્ણ ટ્રાન્સફર માટે મંજૂર સમયથી અલગ છે. પછીનો વધારવાથી એ જ શરૂઆતનો વિરામ અસમજાયેલો રહી શકે છે.

કયો HTTP સંવાદ Expect વહન કરે છે તે પણ ઓળખો. HTTPS લક્ષ્ય તરફ સામાન્ય CONNECT સાથે, વેબસાઇટની અપલોડ આપલે TLS ની અંદર હોય છે; ફોરવર્ડ પ્રોક્સી તેના અંદરના અપેક્ષા હેડરને સાદું નિરીક્ષણ કરતું નથી. ઇન્ટરસેપ્શન કે સ્પષ્ટ-લખાણ ફોરવર્ડિંગ માર્ગ જુદો છે.

અપેક્ષા દૂર કરવી જાણી જોઈને સુસંગતતાની પસંદગી હોઈ શકે, પરંતુ તેનો અર્થ એ છે કે ક્લાયન્ટ વહેલા નકારની જાણ થાય તે પહેલાં મોટું બોડી મોકલવા લાગી શકે. તે વર્તનની વાસ્તવિક જરૂરિયાત સાથે સરખામણી કરો. જૂના પ્રોક્સી માટેના ઐતિહાસિક ઉપાયને દરેક અપલોડમાંથી હેડર કાઢી નાખવાની સાર્વત્રિક સૂચના તરીકે ન વર્ણવો.

સંબંધિત લેખો