প্রক্সির চ্যালেঞ্জের পরে পুনরায় চেষ্টা করা আপলোডের আবার তার বডি দরকার। Jersey 2-এর Apache connector-এর জন্য, যে কনফিগারেশন দিয়ে ওই ক্লায়েন্ট তৈরি হয় তাতে বাফার্ড সত্তা প্রক্রিয়াকরণ বেছে নিন:

ClientConfig config = new ClientConfig();
config.connectorProvider(new ApacheConnectorProvider());
config.property(ClientProperties.PROXY_URI,
                "http://proxy.example.net:8080");
config.property(ClientProperties.REQUEST_ENTITY_PROCESSING,
                RequestEntityProcessing.BUFFERED);

ফলাফল ক্লায়েন্টের মাধ্যমে আপলোড সম্পন্ন করুন। এই টাইপগুলো Jersey client ও Apache-connector প্যাকেজ থেকে আসে; অব্যবহৃত কনফিগারেশন সেট করলে অনুরোধে কোনো প্রভাব পড়ত না।

connector বাফার্ড সত্তাকে Apache-র BufferedHttpEntity-এ মুড়ে দেয়। এর অবাফার্ড স্ট্রিমিং সত্তা পুনরাবৃত্তিযোগ্য নয়। বাফারিং প্রমাণীকরণ প্রবাহকে ব্যবহৃত producer আবার না পড়ে পুনরায় পাঠানো যায় এমন বাইট দেয়।

এটি নিশ্চিত করে না যে একটি 407-এর পরেই প্রমাণীকরণ শেষ হবে। কিছু স্কিম বৈধভাবেই একাধিক বিনিময় চায়, তাই আরেকটি চ্যালেঞ্জকে হারানো অবস্থা ধরার আগে পুরো আলোচনা পরীক্ষা করুন।

বডির আকার মেমরি বাজেটের মধ্যে রাখুন। বড় স্ট্রিমিং আপলোডের জন্য ওই কাজের উপযোগী পুনঃপাঠ কৌশল দরকার; প্রতিটি অনুরোধে বাফারিং চালু করলে আলোচনার ব্যর্থতার বদলে মেমরি শেষ হয়ে যেতে পারে।

সম্পর্কিত নিবন্ধ