ಪ್ರಾಕ್ಸಿ ವಿಫಲವಾದಾಗ OkHttp ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸುತ್ತದೆಯೇ?
ವಿಫಲವಾದ ಪ್ರಾಕ್ಸಿ ನೇರ ಪ್ರವೇಶಕ್ಕೆ ಕಾರಣವಾಗಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸಲು ಕ್ಲೈಂಟ್ ಆವೃತ್ತಿ, ರೂಟಿಂಗ್ ಅಭ್ಯರ್ಥಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಮರುಪ್ರಯತ್ನ ಮಾರ್ಗವನ್ನು ಬಳಸಿ.
ಸಿಸ್ಟಮ್-HTTP-ಪ್ರಾಕ್ಸಿಯ ಐತಿಹಾಸಿಕ ಪ್ರಕರಣದಲ್ಲಿ OkHttp 3.5.0 ನಲ್ಲಿ ತನ್ನ ವರ್ತನೆಯನ್ನು ಬದಲಾಯಿಸಿತು: ಆ ಪ್ರಾಕ್ಸಿ ವಿಫಲವಾದ ನಂತರ ಅದು ನೇರ ಸಂಪರ್ಕವನ್ನು ಪ್ರಯತ್ನಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿತು. ಶಾಂತ ಹಿಂಭಾಗದ ಬಗ್ಗೆ ಹಳೆಯ ವರದಿ ಆ ಬದಲಾವಣೆಗೆ ಮೊದಲಿನ ವರ್ತನೆಯನ್ನು ವಿವರಿಸಬಹುದು.
ಆ ಇತಿಹಾಸ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ರೂಟಿಂಗ್ ನೀತಿಯನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ. ನಿಮ್ಮ ಸ್ವಂತ ಅಪ್ಲಿಕೇಶನ್‌ನಿಂದ ಬಂದ ವರದಿಯನ್ನು ಅರ್ಥೈಸಲು ಈ ಮೂರು ಪರಿಶೀಲನೆಗಳನ್ನು ಅನುಸರಿಸಿ:
- ಪರಿಹರಿಸಿದ OkHttp ಆವೃತ್ತಿಯನ್ನು ಹುಡುಕಿ. ನಕಲಿಸುತ್ತಿರುವ ಉದಾಹರಣೆಯ ವಯಸ್ಸಿನ ಬದಲು ಅಪ್ಲಿಕೇಶನ್‌ನ ಅವಲಂಬನೆ ಮಾಹಿತಿಯನ್ನು ಬಳಸಿ, ಫ್ರೇಮ್‌ವರ್ಕ್ ವಾಸ್ತವವಾಗಿ ಸೇರಿಸುವ ಆವೃತ್ತಿಯೂ ಸೇರಿದಂತೆ.
- ಈ ಕ್ಲೈಂಟ್ ಮಾರ್ಗವನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ ಎಂದು ಹುಡುಕಿ. ಸ್ಪಷ್ಟ ಪ್ರಾಕ್ಸಿ ಮತ್ತು ಕಸ್ಟಮ್ ProxySelector ಬೇರೆ ಬೇರೆ ಸಂರಚನೆಗಳು. ಆಯ್ಕೆದಾರನು ಪ್ರಾಕ್ಸಿಯ ನಂತರ ನೇರ ಅಭ್ಯರ್ಥಿಯನ್ನು ನೀಡಿದರೆ, ಅದು ನೇರ ಪರ್ಯಾಯವನ್ನು ನೀಡುತ್ತಿದೆ.
- ವಿಫಲತೆ ನಿರ್ವಾಹಕನನ್ನು ಅನುಸರಿಸಿ. ಬೇರೆ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಮರುಪ್ರಯತ್ನಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ ಅನ್ನು ಹುಡುಕಿ. ಆ ಬದಲಿಯಿಂದ ಮಾಡಿದ ನೇರ ವಿನಂತಿ ಮೊದಲ ಕ್ಲೈಂಟ್‌ನ ನಿರ್ಧಾರದ ಹೊರಗಿದೆ.
ಕಡ್ಡಾಯ-ಪ್ರಾಕ್ಸಿ ಅಗತ್ಯಕ್ಕಾಗಿ ಸಂಬಂಧಿತ ಕ್ಲೈಂಟ್ ನೀತಿ ನೇರ ಪರ್ಯಾಯ ನೀಡುವ ಬದಲು ನಿಲ್ಲಬೇಕು. ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಮತ್ತು ಮರುಪ್ರಯತ್ನ ಮಾರ್ಗವನ್ನು ಆ ಅಗತ್ಯದ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಿ; ಕೇವಲ 3.5.0 ಬದಲಾವಣೆ ಇಡೀ ಯಂತ್ರದ ಸಂಚಾರ ನಿಯಮವಲ್ಲ.