Java ProxySelector: ಕಾಣೆಯಾದ HTTP ಮತ್ತು HTTPS ಪೋರ್ಟ್‌ಗಳನ್ನು ಸಾಮಾನ್ಯೀಕರಿಸಿ

ಒಂದು ನಿಯಮ http://reports.example:80/ ಅನ್ನು ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ ಆದರೆ http://reports.example/ ಅನ್ನು ನೇರವಾಗಿ ಹೋಗಲು ಬಿಡುತ್ತದೆ. ಆ ಎರಡೂ URL ಗಳು ಒಂದೇ ಸಾಮಾನ್ಯ HTTP ಅಂತ್ಯಬಿಂದುವನ್ನು ವಿವರಿಸುತ್ತವೆ. ವ್ಯತ್ಯಾಸವು ಸಾಮಾನ್ಯವಾಗಿ ಅವುಗಳ ಪಾರ್ಸ್ ಮಾಡಿದ ಪೋರ್ಟ್‌ಗಳನ್ನು ಅಕ್ಷರಶಃ ಹೋಲಿಸುವುದರಿಂದ ಬರುತ್ತದೆ.

URI ನಲ್ಲಿ ಯಾವುದೇ ಪೋರ್ಟ್ ಕಾಣದಿದ್ದಾಗ URI.getPort() -1 ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಅದು ಸ್ಕೀಮ್‌ನ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಮೌಲ್ಯವನ್ನು 80 ರೊಂದಿಗೆ ಹೋಲಿಸುವ ರೂಟಿಂಗ್ ನೀತಿಯು ಎರಡನೇ URL ಅನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳುತ್ತದೆ.

String scheme = uri.getScheme();
int port = uri.getPort();
if (port == -1) {
    if ("http".equalsIgnoreCase(scheme)) port = 80;
    else if ("https".equalsIgnoreCase(scheme)) port = 443;
}

ಹೋಲಿಕೆಯ ಎರಡೂ ಬದಿಗಳಿಗೆ ಅದೇ ಸಾಮಾನ್ಯೀಕರಣವನ್ನು ಅನ್ವಯಿಸಿ. ಕೇವಲ ವಿನಂತಿಯ URI ಸರಿಪಡಿಸಿದರೆ ಬಿಟ್ಟುಹೋದ ಪೋರ್ಟ್ ಇರುವ ಸಂರಚಿತ ಗಮ್ಯಸ್ಥಾನವು ಇನ್ನೂ ಹೊಂದಿಕೆಯಾಗದೆ ಉಳಿಯುತ್ತದೆ. ಹೋಸ್ಟ್, ಪರಿಣಾಮಕಾರಿ ಪೋರ್ಟ್ ಮತ್ತು ಉದ್ದೇಶಿತ ಸ್ಕೀಮ್ ಅನ್ನು ಹೋಲಿಸಿ; ವಿಕೃತ ಅಥವಾ ಹೋಸ್ಟ್ ಇಲ್ಲದ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ದೋಷ ಮಾರ್ಗದ ಮೂಲಕ ತಿರಸ್ಕರಿಸಿ.

ಪ್ರತಿ ಕಾಲ್‌ಬ್ಯಾಕ್ ಅನ್ನು HTTP ನಿರ್ಧಾರವಾಗಿ ಮಾಡಬೇಡಿ

ಕಚ್ಚಾ ಸಾಕೆಟ್ ಸಂಪರ್ಕಗಳಿಗೂ ಡೀಫಾಲ್ಟ್ ಆಯ್ಕೆಗಾರನನ್ನು socket ಸ್ಕೀಮ್‌ನೊಂದಿಗೆ ಕೇಳಬಹುದು. ಕೇವಲ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ ಹೊಂದಿಕೆಯಾದರೆ ಆ ಕಾಲ್‌ಬ್ಯಾಕ್ URL ವಿನಂತಿಗಳಿಗೆ ಉದ್ದೇಶಿಸಿದ HTTP ಪ್ರಾಕ್ಸಿಯನ್ನು ಹಿಂತಿರುಗಿಸಬಾರದು. ಬೆಂಬಲಿಸದ ಸ್ಕೀಮ್‌ಗಳನ್ನು ಹಿಂದಿನ ಆಯ್ಕೆಗಾರನಿಗೆ ನಿಯೋಜಿಸಿ, ಅದರ ಸೂಕ್ತ ವರ್ತನೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ.

ನಿಮ್ಮದನ್ನು ಸ್ಥಾಪಿಸುವ ಮೊದಲು ಆ ಹಿಂದಿನ ಆಯ್ಕೆಗಾರನನ್ನು ಹಿಡಿದಿಡಿ. ಬದಲಿಯ ಒಳಗಿನಿಂದ ಪ್ರಸ್ತುತ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಹುಡುಕುವುದು ಬದಲಿಯನ್ನೇ ಮತ್ತೆ ಕರೆಯಬಹುದು.

ವ್ಯತ್ಯಾಸವನ್ನು ನಿರ್ಣಯಿಸುವಾಗ ಸ್ಕೀಮ್, ಹೋಸ್ಟ್, ಮೂಲ ಪೋರ್ಟ್ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಪೋರ್ಟ್ ಅನ್ನು ದಾಖಲಿಸಿ. JDK ಅನುಷ್ಠಾನಗಳ ನಡುವೆ ಒಂದೇ ಗಮನಿಸಿದ ಸಂಖ್ಯೆ ಅಥವಾ ಕಾಲ್‌ಬ್ಯಾಕ್ ಕ್ರಮವನ್ನು ಅವಲಂಬಿಸಬೇಡಿ. ನೀತಿಯು ಪ್ರತಿ ಒದಗಿಸಿದ URI ಗೆ ಸರಿಯಾದ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು.