જૂની HttpClient 4.2.2 એપ્લિકેશનમાં ક્રેડેન્શિયલ પ્રોવાઇડર અને ઓથેન્ટિકેશન કેશ જુદાં જુદાં કામ કરે છે. પ્રોવાઇડર એકાઉન્ટ પૂરું પાડે છે; કેશ જાણી જોઈને પહેલેથી ગોઠવેલી ઓથેન્ટિકેશન સ્કીમને આગળનું પડકાર આવે તે પહેલાં ભાગ લેવા દે છે.

જૂના પ્રોક્સી-વિશિષ્ટ BasicScheme કન્સ્ટ્રક્ટર માટે, હસ્તાંતરણ આ રીતે દેખાય છે:

AuthCache cache = new BasicAuthCache();
cache.put(proxy, new BasicScheme(ChallengeState.PROXY));

HttpContext context = new BasicHttpContext();
context.setAttribute(ClientContext.AUTH_CACHE, cache);
HttpResponse response = client.execute(request, context);

આ ટુકડો ધારે છે કે client પાસે પહેલેથી જ મેળ ખાતો પ્રોક્સી રૂટ અને ક્રેડેન્શિયલ પ્રોવાઇડર છે. proxy એનું HttpHost છે, અને request એ ખરેખરી કામગીરી છે. કેશ કી એ મધ્યસ્થને વર્ણવવી જોઈએ, ગંતવ્ય વેબસાઇટને નહીં.

ભરેલો સંદર્ભ executeને આપો. એને બનાવીને પછી બીજો સંદર્ભ બનાવતું ઓવરલોડ વાપરવાથી કેશ વિનિમયની બહાર રહી જાય છે. એ ઓથેન્ટિકેશન સ્થિતિ વહેંચવાના પછીના કામ માટે, દર વખતે ખાલી સંદર્ભ ફરી બનાવવાને બદલે યોગ્ય સંદર્ભ રાખો.

સ્પષ્ટ PROXY સ્થિતિ આ જૂની APIની છે. TARGET ગંતવ્યની ઓથેન્ટિકેશન સાથે સંબંધિત છે. નવી HttpClient પેઢીઓએ પેકેજ અને ઓથેન્ટિકેશન API બદલ્યાં છે, તેથી આને હાલના 4.2 કોડ માટે જાળવણી માર્ગદર્શન તરીકે વાપરો, નવા client માટેની રેસિપી તરીકે નહીં.

સામાન્ય પડકાર-ચાલિત વિનિમય હજી પણ સાચો હોઈ શકે. ફક્ત જાણીતા અને ઇચ્છિત પ્રોક્સી માટે જ Basic ઓથેન્ટિકેશન વાવો, અને આગળની કામગીરીને એના જોડાણની જરૂર પડે તે પહેલાં દરેક પ્રતિભાવ વાપરી નાખો અથવા મુક્ત કરો. ઉપયોગી પરિણામ એ એકાઉન્ટ અને કેશ કરેલી સ્કીમ છે જે વિનંતી ખરેખર મોકલતા અમલ સાથે જોડાયેલી હોય છે.

સંબંધિત લેખો