প্রক্সি প্রমাণীকরণের পুনরায় চেষ্টা এবং পুনরাবৃত্তি-অযোগ্য আপলোড বডি

একটি GET প্রক্সির মাধ্যমে প্রমাণীকরণ করতে পারে, কিন্তু একটি POST বা PUT পুনরাবৃত্তি-অযোগ্য বডি বা রিওয়াইন্ড ত্রুটিতে ব্যর্থ হয়। অ্যাকাউন্টটি সঠিক হতে পারে: ক্লায়েন্ট আপলোডটি ইতিমধ্যে ব্যবহার করার পরেও প্রমাণীকরণের বিনিময়ে আরেকটি অনুরোধের প্রয়োজন হতে পারে।

libcurl মাল্টি-পাস প্রমাণীকরণসহ বিভিন্ন ব্যবহারের জন্য seek কলব্যাক নথিভুক্ত করে। Jersey কানেক্টরের আচরণের উপর নির্ভর করে বাফারড এবং চাঙ্কড এনটিটি-প্রসেসিং মোড দেয়। একটি Jersey 2 Apache কানেক্টরের উদাহরণ বাফারড সেটিং দেখায়। এর কোনোটিই অসীম ইন-মেমরি আপলোডকে উপযুক্ত করে না।

যে পদ্ধতি ও বডির উৎস ব্যর্থ হয় তা পুনরুৎপাদন করুন। একটি প্রস্তুতিমূলক GET-এ পুনরায় চালানোর কোনো আপলোড থাকে না, এবং এটি প্রমাণ করে না যে পরবর্তী আপলোড একই সংযোগ বা প্রমাণীকরণ অবস্থা ভাগ করে। একটি নতুন গন্তব্য, ক্লায়েন্ট অবজেক্ট বা সংযোগ নীতি তা বদলাতে পারে। ফাইলভিত্তিক বডি এবং লাইভ স্ট্রিমও আলাদা, যদিও তাদের নমুনা লেখা একই।

যদি বাফার করেন, তার আকারের সীমা, সংরক্ষণের স্থান ও আয়ু নির্ধারণ করুন। সমসাময়িক আপলোড খরচ বহুগুণ বাড়ায়, এবং সংবেদনশীল তথ্য যেখানেই বাফার রাখা হয় সেখানেই থাকে।

পরিচিত সামঞ্জস্যপূর্ণ প্রক্সিতে পূর্ব-প্রমাণীকরণ একটি প্রাথমিক চ্যালেঞ্জ এড়াতে পারে। তবে এটি পরবর্তী প্রতিটি প্রমাণীকরণ রাউন্ড, রিডাইরেক্ট বা বন্ধ সংযোগ বাদ দিতে পারে না, যেগুলো আরেকটি চেষ্টা দাবি করতে পারে।

প্রক্সির উত্তর, বডি ব্যবহারের বিন্দু এবং রিপ্লে ত্রুটি একসাথে রাখুন। তারপর প্রোটোকল রিপ্লে এবং অনিশ্চিত অ্যাপ্লিকেশন ফলাফলের মধ্যে পার্থক্য করুন: একটি জমা তার উত্তর হারানোর আগেই প্রক্রিয়া হয়ে যেতে পারে। আবার পাঠানোর আগে গন্তব্যের আইডেম্পোটেন্সি নিয়ম অনুসরণ করুন।