ಡೌನ್‌ಲೋಡ್ ಮಾಡಿದ ಫೈಲ್ HTTP ಸ್ಥಿತಿ ಸಾಲಿನಿಂದ ಪ್ರಾರಂಭವಾದಾಗ

PDF ಅಥವಾ ಸ್ಪ್ರೆಡ್‌ಶೀಟ್ ಎಂದು ಭಾವಿಸಿದ ಫೈಲ್ HTTP/1.1 200 OK ನಿಂದ ಪ್ರಾರಂಭವಾದರೆ, ಡೌನ್‌ಲೋಡರ್ ಫೈಲಿನ ಬದಲು ಕಚ್ಚಾ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಉಳಿಸಿದೆ. ಈ ಸ್ಕೀಮ್ಯಾಟಿಕ್ ಪ್ರತಿಕ್ರಿಯೆಯಲ್ಲಿ ಕೇವಲ ನಾಲ್ಕು ಬೈಟ್ ವಿಷಯವಿದೆ:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
DATA
0

ಫೈಲ್ DATA ಆಗಿದೆ. ಸ್ಥಿತಿ ಸಾಲು, ಹೆಡರ್‌ಗಳು, ಗಾತ್ರ ಗುರುತು ಮತ್ತು ಅಂತ್ಯಗೊಳಿಸುವ ರಚನೆ HTTP ಗೆ ಸೇರಿವೆ. ಹೆಡರ್‌ಗಳ ಉದ್ದ ಬದಲಾಗುವುದರಿಂದ ನಿಗದಿತ ಸಂಖ್ಯೆಯ ಬೈಟ್‌ಗಳನ್ನು ತೆಗೆಯುವುದು ಸುರಕ್ಷಿತವಲ್ಲ. ಮೊದಲ ಖಾಲಿ ಸಾಲಿನ ನಂತರದ ಎಲ್ಲವನ್ನೂ ನಕಲಿಸಿದರೂ ಚಂಕ್ ಚೌಕಟ್ಟು ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಮಾಹಿತಿ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಅಂತಿಮ ಪ್ರತಿಕ್ರಿಯೆಗೆ ಮೊದಲು ಬರಬಹುದು.

ಸಾಮಾನ್ಯ ಡೌನ್‌ಲೋಡ್‌ಗೆ, ಕಚ್ಚಾ ಸಾಕೆಟ್‌ನಿಂದ ಫೈಲ್‌ಗೆ ನಕಲಿಸುವುದನ್ನು HTTP ಕ್ಲೈಂಟ್‌ನ ಪ್ರತಿಕ್ರಿಯೆ-ದೇಹದ ಇಂಟರ್‌ಫೇಸ್‌ನಿಂದ ಬದಲಾಯಿಸಿ. ಅದರ ಪ್ರಾಕ್ಸಿಯನ್ನು ಸಂರಚಿಸಿ, ಅಂತಿಮ ಸ್ಥಿತಿಯನ್ನು ಮೌಲ್ಯೀಕರಿಸಿ ಮತ್ತು ದೇಹವನ್ನು ತಾತ್ಕಾಲಿಕ ಔಟ್‌ಪುಟ್‌ಗೆ ಸ್ಟ್ರೀಮ್ ಮಾಡಿ. ಕ್ಲೈಂಟ್ ಸಂದೇಶದ ಚೌಕಟ್ಟನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ಉದ್ದ, ಚಂಕ್ ಮತ್ತು ಸಂಪರ್ಕದಿಂದ ಸೀಮಿತವಾದ ದೇಹಗಳಿಗೆ ವಿಭಿನ್ನ ಪಾರ್ಸಿಂಗ್ ಬೇಕು.

ವಿಷಯ ಎನ್‌ಕೋಡಿಂಗ್ ಇನ್ನೊಂದು ಪದರ. ಕ್ಲೈಂಟ್‌ನ ದಾಖಲಿತ ವರ್ತನೆಯ ಆಧಾರದ ಮೇಲೆ ನಿಮಗೆ ಡಿಕೋಡ್ ಮಾಡಿದ ಫೈಲ್ ಬೈಟ್‌ಗಳು ಬೇಕೋ ಅಥವಾ ಸ್ಪಷ್ಟವಾಗಿ ಕೇಳಿದ ಕಚ್ಚಾ ವಿಷಯ ಬೇಕೋ ಎಂದು ನಿರ್ಧರಿಸಿ. ಸಂಕುಚಿತ ಬೈಟ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾಕ್ಸಿ ಭ್ರಷ್ಟಾಚಾರವಲ್ಲ.

ಅಪ್ಲಿಕೇಶನ್ ಸಾಕೆಟ್ ಮಟ್ಟದ ಕೋಡ್ ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳಬೇಕಾದರೆ, ಆ ಎಲ್ಲಾ ಪಾರ್ಸಿಂಗ್ ನಿಯಮಗಳು ಮತ್ತು ಓದು-ಬರಹ ನಿರ್ವಹಣೆ ಅದರದೇ. ಓದುವಿಕೆಯು ವಾಸ್ತವವಾಗಿ ಹಿಂತಿರುಗಿಸಿದ ಬೈಟ್ ಸಂಖ್ಯೆಯನ್ನು ಮಾತ್ರ ಬರೆಯಿರಿ, ಬಫರ್‌ನ ಸಾಮರ್ಥ್ಯವನ್ನಲ್ಲ, ಮತ್ತು ಭಾಗಶಃ ಬರವಣಿಗೆಗಳನ್ನು ನಿರ್ವಹಿಸಿ. ಇಲ್ಲದಿದ್ದರೆ ಹಳೆಯ ಬಫರ್ ವಿಷಯವು ಸರಿಯಾಗಿ ಹೊರತೆಗೆದ ದೇಹವನ್ನೂ ಹಾಳುಮಾಡಬಹುದು.

HTTPS ಗೆ CONNECT ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ತೆಗೆದುಹಾಕುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ಬೇಕು: ಸುರಂಗವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಸ್ಥಾಪಿಸಿದ ನಂತರ ಗಮ್ಯಸ್ಥಾನದ TLS ಅನ್ನು ಸ್ಥಾಪಿಸಿ, ನಂತರ ಒಳಗಿನ HTTP ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ. ಪ್ರಾಕ್ಸಿಯ ಹೆಡರ್‌ಗಳ ನಂತರ ಬರುವ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಬೈಟ್‌ಗಳು ಡೌನ್‌ಲೋಡ್ ಮಾಡಬಹುದಾದ ಫೈಲ್ ಅಲ್ಲ.

ವಿಫಲವಾದ ಅಥವಾ ಅಪೂರ್ಣ ಔಟ್‌ಪುಟ್ ಅನ್ನು ತಾತ್ಕಾಲಿಕ ಹೆಸರಿನಲ್ಲಿ ಇರಿಸಿ. ವರ್ಗಾವಣೆ ಮತ್ತು ಫೈಲ್ ಪರಿಶೀಲನೆಗಳು ಯಶಸ್ವಿಯಾದ ನಂತರವೇ ಅದನ್ನು ಪ್ರಕಟಿಸಿ; ಖಾಲಿವಲ್ಲದ ಫೈಲ್ ಪೂರ್ಣ ಡೌನ್‌ಲೋಡ್ ಅನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.