HTTP ಅಪ್‌ಲೋಡ್ ವಿರಾಮಗಳು ಮತ್ತು Expect: 100-continue
Expect: 100-continue ವಿನಿಮಯವನ್ನು ಗುರುತಿಸಿ ಮತ್ತು ಅದರ ಸಣ್ಣ ನಿರ್ಣಯ ಬಿಂದುವನ್ನು ಡೇಟಾ ವರ್ಗಾವಣೆ ವೇಳೆ ನಿಂತ ಅಪ್‌ಲೋಡ್‌ನಿಂದ ಬೇರ್ಪಡಿಸಿ.
ಸಂಪರ್ಕ ತೆರೆಯುತ್ತದೆ. ವಿನಂತಿಯ ಹೆಡರ್‌ಗಳು ಹೊರಡುತ್ತವೆ. ಫೈಲ್ ಚಲಿಸುತ್ತಿಲ್ಲ ಎನಿಸುತ್ತದೆ. ಒಂದು ವಿವರಣೆ ಎಂದರೆ ಕ್ಲೈಂಟ್ ತನ್ನ ಬಾಡಿ ಕಳುಹಿಸುವ ಮೊದಲು Expect: 100-continue ಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ಕಾಯುತ್ತಿದೆ.
ಈ ಕಾರ್ಯವಿಧಾನವು ಸ್ವೀಕರಿಸುವವರಿಗೆ ಸಂಭಾವ್ಯ ದೊಡ್ಡ ಅಪ್‌ಲೋಡ್ ಕಳುಹಿಸುವ ಮೊದಲು ಹೆಡರ್‌ಗಳ ಆಧಾರದಲ್ಲಿ ವಿನಂತಿಯನ್ನು ತಿರಸ್ಕರಿಸಲು ಅವಕಾಶ ನೀಡುತ್ತದೆ. ಸಾಮಾನ್ಯ ಯಶಸ್ವಿ ಕ್ರಮ:
request headers → 100 Continue → request body → final response100 ಮಾಹಿತಿಪೂರ್ಣವಾಗಿದೆ: ಅದು ಕ್ಲೈಂಟ್ ಮುಂದುವರಿಯಲು ಅನುಮತಿಸುತ್ತದೆ, ಆದರೆ ಫೈಲ್ ಸಂಗ್ರಹವಾಗಿದೆ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯಾಚರಣೆ ಯಶಸ್ವಿಯಾಗಿದೆ ಎಂದು ಅರ್ಥವಲ್ಲ. Git push HTTP 417 ಹಿಂತಿರುಗಿಸುವುದು ನಿರೀಕ್ಷೆ ವಿಫಲತೆಯ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸಂದರ್ಭ.
ಕ್ಲೈಂಟ್ ಯಾವ ಪ್ರತಿಕ್ರಿಯೆ ಪಡೆದಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ
| ವೀಕ್ಷಣೆ | ತನಿಖೆ ಮಾಡಬೇಕಾದ ಅರ್ಥ |
|---|---|
| 100 Continue | ಕ್ಲೈಂಟ್ ಬಾಡಿಯೊಂದಿಗೆ ಮುಂದುವರಿಯಬಹುದು |
| ಬಾಡಿಗೆ ಮೊದಲು ಅಂತಿಮ ತಿರಸ್ಕಾರ | ಹೆಡರ್ ಹಂತದಲ್ಲಿ ಕಾರ್ಯಾಚರಣೆ ತಿರಸ್ಕೃತವಾಯಿತು |
| ನಿರೀಕ್ಷಿತ ಮಧ್ಯಂತರ ಪ್ರತಿಕ್ರಿಯೆ ಇಲ್ಲ | ಕ್ಲೈಂಟ್‌ನ ಕಾಯುವ ನೀತಿ ಮತ್ತು ಆ ಮಾರ್ಗದಲ್ಲಿ ನಿರ್ವಹಣೆ |
curl expect-continue ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಕಾಯುವ ಸೆಟ್ಟಿಂಗ್ ನೀಡುತ್ತದೆ. ಆ libcurl ಕಾಯುವಿಕೆ ನಿರೀಕ್ಷಿತ ಪ್ರತಿಕ್ರಿಯೆ ಇಲ್ಲದೆ ಮುಗಿದರೆ, ಅದು ಬಾಡಿಯನ್ನು ಹೇಗಾದರೂ ಕಳುಹಿಸುತ್ತದೆ; ಮುಗಿಯುವುದು ತಾನಾಗಿಯೇ ಇಡೀ ವರ್ಗಾವಣೆಯ ವಿಫಲತೆ ಅಲ್ಲ. ಸೆಟ್ಟಿಂಗ್ ಪೂರ್ಣ ವರ್ಗಾವಣೆಗೆ ಅನುಮತಿಸಿದ ಸಮಯದಿಂದ ಬೇರೆಯಾಗಿದೆ. ಎರಡನೆಯದನ್ನು ಹೆಚ್ಚಿಸುವುದು ಅದೇ ಆರಂಭಿಕ ವಿರಾಮವನ್ನು ವಿವರಣೆ ಇಲ್ಲದೆ ಬಿಡಬಹುದು.
Expect ಅನ್ನು ಯಾವ HTTP ಸಂವಾದ ಹೊತ್ತೊಯ್ಯುತ್ತದೆ ಎಂದೂ ಗುರುತಿಸಿ. HTTPS ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸಾಮಾನ್ಯ CONNECT ನಲ್ಲಿ ವೆಬ್‌ಸೈಟ್‌ನ ಅಪ್‌ಲೋಡ್ ವಿನಿಮಯ TLS ಒಳಗಿರುತ್ತದೆ; ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ ಅದರ ಒಳಗಿನ ನಿರೀಕ್ಷಾ ಹೆಡರ್ ಅನ್ನು ಸರಳವಾಗಿ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಪ್ರತಿಬಂಧ ಅಥವಾ ಸ್ಪಷ್ಟ-ಪಠ್ಯ ಮುಂದುವರಿಸುವ ಮಾರ್ಗ ಬೇರೆ.
ನಿರೀಕ್ಷೆಯನ್ನು ತೆಗೆದುಹಾಕುವುದು ಉದ್ದೇಶಪೂರ್ವಕ ಹೊಂದಾಣಿಕೆಯ ಆಯ್ಕೆಯಾಗಿರಬಹುದು, ಆದರೆ ಅದರ ಅರ್ಥ ಕ್ಲೈಂಟ್ ಆರಂಭಿಕ ತಿರಸ್ಕಾರದ ಬಗ್ಗೆ ತಿಳಿಯುವ ಮೊದಲು ದೊಡ್ಡ ಬಾಡಿ ಕಳುಹಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಆ ನಡವಳಿಕೆಯನ್ನು ನಿಜವಾದ ಅಗತ್ಯದೊಂದಿಗೆ ಹೋಲಿಸಿ. ಹಳೆಯ ಪ್ರಾಕ್ಸಿಗೆ ಮಾಡಿದ ಐತಿಹಾಸಿಕ ಪರಿಹಾರವನ್ನು ಪ್ರತಿ ಅಪ್‌ಲೋಡ್‌ನಿಂದ ಹೆಡರ್ ತೆಗೆಯುವ ಸಾರ್ವತ್ರಿಕ ಸೂಚನೆ ಎಂದು ವಿವರಿಸಬೇಡಿ.