പ്രോക്സി പരാജയപ്പെടുമ്പോൾ OkHttp നേരിട്ട് കണക്റ്റ് ചെയ്യുമോ?
പരാജയപ്പെട്ട പ്രോക്സി നേരിട്ടുള്ള ആക്സസിലേക്ക് നയിച്ചേക്കാമോ എന്ന് തീരുമാനിക്കാൻ ക്ലയന്റ് പതിപ്പ്, റൂട്ടിംഗ് സ്ഥാനാർത്ഥികൾ, ആപ്ലിക്കേഷന്റെ വീണ്ടും ശ്രമിക്കാനുള്ള പാത എന്നിവ ഉപയോഗിക്കുക.
സിസ്റ്റം HTTP പ്രോക്സിയുടെ ചരിത്രപരമായ സന്ദർഭത്തിൽ, OkHttp 3.5.0-ൽ അതിന്റെ സ്വഭാവം മാറ്റി: ആ പ്രോക്സി പരാജയപ്പെട്ടതിനുശേഷം അത് നേരിട്ടുള്ള കണക്ഷൻ ശ്രമിക്കുന്നത് നിർത്തി. നിശബ്ദമായ തിരിച്ചുപോക്കിനെക്കുറിച്ചുള്ള പഴയൊരു റിപ്പോർട്ട് ആ മാറ്റത്തിനുമുമ്പുള്ള സ്വഭാവം വിവരിച്ചേക്കാം.
ആ ചരിത്രം ഓരോ ആപ്ലിക്കേഷന്റെയും റൂട്ടിംഗ് നയം തീരുമാനിക്കുന്നില്ല. നിങ്ങളുടെ സ്വന്തം ആപ്ലിക്കേഷനിൽനിന്നുള്ള റിപ്പോർട്ട് വ്യാഖ്യാനിക്കാൻ ഈ മൂന്ന് പരിശോധനകൾ പാലിക്കുക:
- പരിഹരിച്ച OkHttp പതിപ്പ് കണ്ടെത്തുക. പകർത്തുന്ന ഉദാഹരണത്തിന്റെ പ്രായത്തിനുപകരം, ഒരു ഫ്രെയിംവർക്ക് യഥാർത്ഥത്തിൽ ഉൾപ്പെടുത്തിയ പതിപ്പ് ഉൾപ്പെടെ ആപ്ലിക്കേഷന്റെ ആശ്രിത വിവരങ്ങൾ ഉപയോഗിക്കുക.
- ഈ ക്ലയന്റ് എങ്ങനെ റൂട്ട് തിരഞ്ഞെടുക്കുന്നു എന്ന് കണ്ടെത്തുക. വ്യക്തമായ പ്രോക്സിയും ഇഷ്ടാനുസൃത ProxySelector-ഉം വ്യത്യസ്ത കോൺഫിഗറേഷനുകളാണ്. സെലക്ടർ ഒരു പ്രോക്സിക്കുശേഷം നേരിട്ടുള്ള സ്ഥാനാർത്ഥി നൽകിയാൽ, അത് നേരിട്ടുള്ള ബദൽ വാഗ്ദാനം ചെയ്യുന്നു.
- പരാജയ ഹാൻഡ്ലർ പിന്തുടരുക. മറ്റൊരു ക്ലയന്റിനൊപ്പം വീണ്ടും ശ്രമിക്കുന്ന ആപ്ലിക്കേഷൻ കോഡ് തിരയുക. ആ പകരക്കാരൻ നടത്തുന്ന നേരിട്ടുള്ള അഭ്യർത്ഥന ആദ്യ ക്ലയന്റിന്റെ തീരുമാനത്തിന് പുറത്താണ്.
നിർബന്ധിത പ്രോക്സി ആവശ്യകതയ്ക്ക്, ബന്ധപ്പെട്ട ക്ലയന്റ് നയം നേരിട്ടുള്ള ബദൽ വാഗ്ദാനം ചെയ്യുന്നതിനുപകരം നിർത്തണം. യഥാർത്ഥ ക്ലയന്റും വീണ്ടും ശ്രമിക്കാനുള്ള പാതയും ആ ആവശ്യകതയ്ക്കെതിരെ പരിശോധിക്കുക; 3.5.0 മാറ്റം മാത്രം യന്ത്രം മുഴുവനുള്ള ട്രാഫിക് നിയമമല്ല.