પ્રોક્સી પ્રમાણીકરણના ફરી પ્રયાસો અને પુનરાવર્તન ન થઈ શકે તેવા અપલોડ બોડી
સમજો કે પ્રમાણીકરણના ફરી પ્રયાસો એક-વખતના અપલોડ પ્રવાહને કેવી રીતે ખુલ્લો કરી શકે છે, અને મર્યાદિત બફરિંગ અથવા પુનરાવર્તનયોગ્ય સામગ્રી જાણી જોઈને પસંદ કરો.
GET પ્રોક્સી દ્વારા પ્રમાણીકરણ કરી શકે છે જ્યારે POST અથવા PUT પુનરાવર્તન ન થઈ શકે તેવા બોડી અથવા રીવાઇન્ડ ભૂલ સાથે નિષ્ફળ જાય છે. ખાતું સાચું હોઈ શકે: ક્લાયન્ટ અપલોડ વાપરી લીધા પછી પણ પ્રમાણીકરણની આપલેને બીજી વિનંતીની જરૂર પડી શકે છે.
| બોડીનો સ્રોત | ફરી ચલાવવાનો વિકલ્પ |
|---|---|
| નાનું મર્યાદિત બોડી | મર્યાદિત બફર તેના બાઇટ્સ રાખી શકે છે. |
| શોધી શકાય તેવી ફાઇલ | ક્લાયન્ટ દ્વારા સમર્થિત રીવાઇન્ડ ઇન્ટરફેસ તેને પુનરાવર્તનયોગ્ય બનાવી શકે છે. |
| જનરેટર, પાઇપ અથવા લાઇવ ઉત્પાદક | એક-વખતના સ્રોત માટે બીજી રચનાની જરૂર પડી શકે છે. |
libcurl બહુ-પાસ પ્રમાણીકરણ સહિતના ઉપયોગો માટે શોધ કૉલબેકનું દસ્તાવેજીકરણ કરે છે. Jersey કનેક્ટરના વર્તનને આધીન બફર કરેલા અને ચંક કરેલા એન્ટિટી-પ્રોસેસિંગ મોડ આપે છે. એક Jersey 2 Apache કનેક્ટરનું ઉદાહરણ બફર કરેલું સેટિંગ દર્શાવે છે. તેમાંથી કોઈ પણ અમર્યાદિત ઇન-મેમરી અપલોડને યોગ્ય બનાવતું નથી.
જે પદ્ધતિ અને બોડીનો સ્રોત નિષ્ફળ જાય તે ફરી ઉત્પન્ન કરો. પ્રારંભિક GET પાસે ફરી ચલાવવા માટે કોઈ અપલોડ નથી, અને તે સાબિત કરતું નથી કે પછીનું અપલોડ તેના જોડાણ અથવા પ્રમાણીકરણ સ્થિતિને વહેંચે છે. નવું લક્ષ્ય, ક્લાયન્ટ ઑબ્જેક્ટ અથવા જોડાણ નીતિ તેને બદલી શકે છે. ફાઇલ-આધારિત બોડી અને લાઇવ સ્ટ્રીમ પણ અલગ છે, પછી ભલે તેમનો નમૂનાનો ટેક્સ્ટ સમાન હોય.
જો તમે બફર કરો છો, તો તેની કદ મર્યાદા, સંગ્રહ સ્થાન અને જીવનકાળ વ્યાખ્યાયિત કરો. એક સાથેના અપલોડ ખર્ચને ગુણાકાર કરે છે, અને સંવેદનશીલ ડેટા જ્યાં બફર રાખવામાં આવે છે ત્યાં જ રહે છે.
જાણીતા સુસંગત પ્રોક્સી માટે પૂર્વ-પ્રમાણીકરણ એક પ્રારંભિક પડકાર ટાળી શકે છે. તે પછીના દરેક પ્રમાણીકરણ રાઉન્ડ, રીડાયરેક્ટ અથવા બંધ જોડાણને બાકાત કરી શકતું નથી જે બીજા પ્રયાસની માંગ કરી શકે.
પ્રોક્સીનો જવાબ, બોડી વપરાશનું બિંદુ અને રિપ્લે ભૂલ એકસાથે રાખો. પછી પ્રોટોકોલ રિપ્લેને અનિશ્ચિત એપ્લિકેશન પરિણામથી અલગ પાડો: સબમિશન તેના જવાબ ગુમાવતા પહેલા પ્રક્રિયા થઈ શકે છે. ફરી મોકલતા પહેલા લક્ષ્યના idempotency નિયમોનું પાલન કરો.