प्रॉक्सी प्रमाणीकरण पुनःप्रयासों के लिए Jersey 2 अपलोड को बफ़र करना

प्रॉक्सी चुनौती के बाद दोबारा आज़माया गया अपलोड अपने मुख्य भाग की फिर ज़रूरत रखता है। 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 में लपेटता है। इसकी गैर-बफ़र्ड स्ट्रीमिंग इकाई दोहराने योग्य नहीं है। बफ़रिंग प्रमाणीकरण प्रवाह को खपत किए गए उत्पादक को फिर पढ़ने के बजाय दोबारा भेजे जा सकने वाले बाइट देती है।

यह निश्चित नहीं करता कि एक 407 के बाद प्रमाणीकरण खत्म हो जाए। कुछ योजनाओं में वैध रूप से कई आदान-प्रदान लगते हैं, इसलिए किसी और चुनौती को खोई हुई स्थिति मानने से पहले पूरी बातचीत जाँचें।

मुख्य भाग का आकार स्मृति बजट में रखें। बड़े स्ट्रीमिंग अपलोड के लिए उस कार्यभार के अनुरूप पुनःप्रसारण रणनीति चाहिए; हर अनुरोध के लिए बफ़रिंग चालू करने से बातचीत की विफलता के बदले स्मृति खत्म हो सकती है।