ಅಪ್‌ಲೋಡ್ ಅನ್ನು ತುಣುಕುಗಳಲ್ಲಿ ಓದಲು chunked HTTP ಅಗತ್ಯವಿಲ್ಲ

ಇಲ್ಲ. ಕ್ಲೈಂಟ್ ದೊಡ್ಡ ಫೈಲ್ ಅನ್ನು ಸಣ್ಣ ಬಫರ್‌ಗಳಲ್ಲಿ ಓದಿ ತಿಳಿದಿರುವ Content-Length ಜೊತೆ ಕಳುಹಿಸಬಹುದು. ಸೀಮಿತ ಓದುಗಳು ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ; HTTP ಫ್ರೇಮಿಂಗ್ ವಿನಂತಿಯ ದೇಹ ಎಲ್ಲಿ ಮುಗಿಯುತ್ತದೆ ಎಂದು ಸ್ವೀಕರಿಸುವವರಿಗೆ ತಿಳಿಸುತ್ತದೆ.

HTTP ಗ್ರಂಥಾಲಯಕ್ಕೆ ಬೈಟ್ ಉದ್ದ ತಿಳಿದಿರುವ ಸ್ಥಿರ ಫೈಲ್, ಅಜ್ಞಾತ ಪ್ರಮಾಣದ ಡೇಟಾವನ್ನು ಉತ್ಪಾದಿಸುವ ಜನರೇಟರ್‌ಗಿಂತ ಭಿನ್ನ. ಎರಡೂ ಮೂಲಗಳಿಗೆ ಗ್ರಂಥಾಲಯ ಬೆಂಬಲಿಸುವ ದೇಹ ಇಂಟರ್ಫೇಸ್ ಬಳಸಿ. ಕೇವಲ ಉದ್ದ ನೀಡಲು ಇಡೀ ಫೈಲ್ ಅನ್ನು ಸ್ಟ್ರಿಂಗ್‌ನಲ್ಲಿ ಜೋಡಿಸುವ ಅಗತ್ಯವಿಲ್ಲ.

HTTP/1.1 ಗಾಗಿ, ಪ್ರೋಟೋಕಾಲ್ ನಿಯಮಗಳ ಪ್ರಕಾರ ನಿಜವಾಗಿ ಕಳುಹಿಸಲಾದ ಫ್ರೇಮಿಂಗ್ ಪರಿಶೀಲಿಸಿ: Content-Length ಅಥವಾ chunked ವರ್ಗಾವಣೆ ಕೋಡಿಂಗ್. Chunked ಕೋಡಿಂಗ್ ಫೈಲ್ ವಿಷಯದ ಹೊರಗೆ ಗಾತ್ರದ ಗುರುತುಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ. ವಿರೋಧಾಭಾಸದ ಫ್ರೇಮಿಂಗ್ ಕ್ಷೇತ್ರಗಳನ್ನು ಸಂಯೋಜಿಸಬೇಡಿ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯನ್ನು ಅಪ್‌ಲೋಡ್ ಸ್ವೀಕರಿಸಲು ಒಪ್ಪಿಸಲು ಉದ್ದವನ್ನು ಊಹಿಸಬೇಡಿ.

ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಅಪ್‌ಲೋಡ್ ವಿಫಲವಾದರೆ, HTTP ಆವೃತ್ತಿ, ದೇಹದ ಮೂಲ ಮತ್ತು ಮೊದಲ ನಿರಾಕರಣೆಯನ್ನು ದಾಖಲಿಸಿ. 411 ಪ್ರತಿಕ್ರಿಯೆ ದೇಹದ ಮಧ್ಯದಲ್ಲಿ ಮುಚ್ಚುವ ಸಂಪರ್ಕಕ್ಕಿಂತ ಬೇರೆ ತನಿಖೆಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ಬದಲಾಗಿ ದೃಢೀಕರಣ ಮರುಪ್ರಯತ್ನಗಳು ವಿಫಲವಾದರೆ, ಅಪ್‌ಲೋಡ್ ದೇಹವನ್ನು ಮತ್ತೆ ಪ್ಲೇ ಮಾಡಬಹುದೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಅಪ್ಲಿಕೇಶನ್‌ನ ರೀಡ್-ಬಫರ್ ಗಾತ್ರವನ್ನು ಬದಲಿಸುವುದು ವಿನಂತಿಯ ಫ್ರೇಮಿಂಗ್ ಅನ್ನು ಹಿಂದಿದ್ದಂತೆಯೇ ಬಿಡಬಹುದು.

ಆ ವೀಕ್ಷಣೆಗೆ ಮಾರ್ಗ ಮುಖ್ಯ. ಸ್ಪಷ್ಟ ಪಠ್ಯ ಮುಂದುವರಿಕೆ ಅಪ್‌ಲೋಡ್‌ನ HTTP ಫ್ರೇಮಿಂಗ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿಗೆ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ; ಸಾಮಾನ್ಯ ಎಂಡ್-ಟು-ಎಂಡ್ HTTPS ಅದನ್ನು ಸುರಂಗದೊಳಗೆ ಇಡುತ್ತದೆ. HTTP/2 ತನ್ನದೇ ಫ್ರೇಮಿಂಗ್ ಬಳಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಐತಿಹಾಸಿಕ Squid ಮಿತಿಗಳು ಕೆಲವು ಹಳೆಯ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ, ಇಂದಿನ ಪ್ರತಿ ಪ್ರಾಕ್ಸಿಯೂ ಸ್ಟ್ರೀಮ್ ಮಾಡಿದ ಅಪ್‌ಲೋಡ್‌ಗಳನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ ಎಂಬ ನಿಯಮವಲ್ಲ.