ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣದ ಮರು ಪ್ರಯತ್ನಗಳು ಮತ್ತು ಮರುಪರಿಚಯಿಸಲಾಗದ ಅಪ್ಲೋಡ್ ಬಾಡಿಗಳು

GET ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ದೃಢೀಕರಿಸಬಹುದು, ಆದರೆ POST ಅಥವಾ PUT ಮರುಪರಿಚಯಿಸಲಾಗದ ಬಾಡಿ ಅಥವಾ ರಿವೈಂಡ್ ದೋಷದೊಂದಿಗೆ ವಿಫಲವಾಗುತ್ತದೆ. ಖಾತೆ ಸರಿಯಾಗಿರಬಹುದು: ಕ್ಲೈಂಟ್ ಅಪ್ಲೋಡ್ ಅನ್ನು ಈಗಾಗಲೇ ಬಳಸಿಕೊಂಡ ನಂತರವೂ ದೃಢೀಕರಣ ವಿನಿಮಯಕ್ಕೆ ಇನ್ನೊಂದು ವಿನಂತಿ ಬೇಕಾಗಬಹುದು.

libcurl ಬಹು-ಹಂತದ ದೃಢೀಕರಣ ಸೇರಿದಂತೆ ಉಪಯೋಗಗಳಿಗೆ ಹುಡುಕಾಟ ಕಾಲ್ಬ್ಯಾಕ್ಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. Jersey ಕನೆಕ್ಟರ್ನ ವರ್ತನೆಗೆ ಒಳಪಟ್ಟು ಬಫರ್ಡ್ ಮತ್ತು ಚಂಕ್ಡ್ ಎಂಟಿಟಿ-ಪ್ರಾಸೆಸಿಂಗ್ ಮೋಡ್ಗಳನ್ನು ನೀಡುತ್ತದೆ. Jersey 2 Apache ಕನೆಕ್ಟರ್ ಉದಾಹರಣೆ ಬಫರ್ಡ್ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ತೋರಿಸುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಅಪರಿಮಿತ ಇನ್-ಮೆಮೊರಿ ಅಪ್ಲೋಡ್ಗಳನ್ನು ಸೂಕ್ತವಾಗಿಸುವುದಿಲ್ಲ.

ವಿಫಲವಾಗುವ ವಿಧಾನ ಮತ್ತು ಬಾಡಿ ಮೂಲವನ್ನು ಮರುಸೃಷ್ಟಿಸಿ. ಪೂರ್ವಸಿದ್ಧತಾ GET ನಲ್ಲಿ ಮರುಪರಿಚಯಿಸಲು ಅಪ್ಲೋಡ್ ಇಲ್ಲ, ಮತ್ತು ನಂತರದ ಅಪ್ಲೋಡ್ ಅದರ ಸಂಪರ್ಕ ಅಥವಾ ದೃಢೀಕರಣ ಸ್ಥಿತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಅದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಹೊಸ ಗಮ್ಯಸ್ಥಾನ, ಕ್ಲೈಂಟ್ ಆಬ್ಜೆಕ್ಟ್ ಅಥವಾ ಸಂಪರ್ಕ ನೀತಿ ಅದನ್ನು ಬದಲಾಯಿಸಬಹುದು. ಫೈಲ್-ಆಧಾರಿತ ಬಾಡಿ ಮತ್ತು ಲೈವ್ ಸ್ಟ್ರೀಮ್ ಕೂಡ ಅವುಗಳ ಮಾದರಿ ಪಠ್ಯ ಒಂದೇ ಆಗಿದ್ದರೂ ಭಿನ್ನವಾಗಿವೆ.

ನೀವು ಬಫರ್ ಮಾಡಿದರೆ, ಅದರ ಗಾತ್ರ ಮಿತಿ, ಸಂಗ್ರಹಣಾ ಸ್ಥಳ ಮತ್ತು ಜೀವಿತಾವಧಿಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ. ಏಕಕಾಲಿಕ ಅಪ್ಲೋಡ್ಗಳು ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸುತ್ತವೆ, ಮತ್ತು ಸೂಕ್ಷ್ಮ ಡೇಟಾ ಬಫರ್ ಇರಿಸುವ ಎಲ್ಲಿಯೂ ಉಳಿಯುತ್ತದೆ.

ತಿಳಿದಿರುವ ಹೊಂದಾಣಿಕೆಯ ಪ್ರಾಕ್ಸಿಗೆ ಪೂರ್ವ-ದೃಢೀಕರಣ ಒಂದು ಆರಂಭಿಕ ಸವಾಲನ್ನು ತಪ್ಪಿಸಬಹುದು. ಆದರೆ ಇನ್ನೊಂದು ಪ್ರಯತ್ನ ಬೇಕಾಗಬಹುದಾದ ಪ್ರತಿ ನಂತರದ ದೃಢೀಕರಣ ಸುತ್ತು, ಮರುನಿರ್ದೇಶನ ಅಥವಾ ಮುಚ್ಚಿದ ಸಂಪರ್ಕವನ್ನು ಅದು ಹೊರಗಿಡಲಾರದು.

ಪ್ರಾಕ್ಸಿ ಪ್ರತಿಕ್ರಿಯೆ, ಬಾಡಿ ಬಳಕೆಯ ಬಿಂದು ಮತ್ತು ಮರುಪರಿಚಯಿಸುವ ದೋಷವನ್ನು ಒಟ್ಟಿಗೆ ಇರಿಸಿ. ನಂತರ ಪ್ರೋಟೋಕಾಲ್ ಮರುಪರಿಚಯವನ್ನು ಅನಿಶ್ಚಿತ ಅಪ್ಲಿಕೇಶನ್ ಫಲಿತಾಂಶದಿಂದ ಪ್ರತ್ಯೇಕಿಸಿ: ಸಲ್ಲಿಕೆಯ ಪ್ರತಿಕ್ರಿಯೆ ಕಳೆದುಹೋಗುವ ಮೊದಲು ಅದು ಸಂಸ್ಕರಿಸಲ್ಪಟ್ಟಿರಬಹುದು. ಮತ್ತೆ ಕಳುಹಿಸುವ ಮೊದಲು ಗಮ್ಯಸ್ಥಾನದ idempotency ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸಿ.