ಫಾರ್ವರ್ಡ್ ಪ್ರಾಕ್ಸಿ ವಿನಂತಿ ಸಾಲು ಮತ್ತು ಹೆಡರ್‌ಗಳನ್ನು ಓದಿ, ಅವುಗಳನ್ನು ರವಾನಿಸಿ, ನಂತರ select ನಲ್ಲಿ POST ಬಾಡಿಗಾಗಿ ಕಾಯುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಅದನ್ನು ಈಗಾಗಲೇ ಕಳುಹಿಸಿದೆ. ಎರಡೂ ಕಡೆ ಪರಸ್ಪರ ಕಾಯುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ.

Python ನ BaseHTTPRequestHandler ನಲ್ಲಿ ಹೆಡರ್ ಓದುವುದು rfile ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಅದು ಬಫರ್ ಮಾಡಿದ ಇನ್‌ಪುಟ್ ಸ್ಟ್ರೀಮ್. ಆ ಸ್ಟ್ರೀಮ್ ಮುಂದೆ ಓದಬಹುದು ಮತ್ತು ಬಾಡಿಗೆ ಸೇರಿದ ಬೈಟ್‌ಗಳನ್ನು ಹಿಡಿದಿಡಬಹುದು. ಕೆಳಗಿನ socket ಮೇಲೆ ಕಾಯುವುದು ಅದರ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಸಿದ್ಧವಿದೆಯೇ ಎಂದು ಮಾತ್ರ ಕೇಳುತ್ತದೆ; Python ಸ್ಟ್ರೀಮ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಬಳಸಬಹುದಾದ ಡೇಟಾ ಇದೆಯೇ ಎಂದು ಕೇಳುವುದಿಲ್ಲ.

ಹೆಡರ್ ಓದಿದ ಬಫರ್ ಅನ್ನು ಅನುಸರಿಸಿ

ಬಾಡಿಯನ್ನೂ self.rfile ಮೂಲಕ ಓದಿ. ಬಫರ್ ಮಾಡಿದ ಸ್ಟ್ರೀಮ್‌ನಿಂದ ಹೆಡರ್ ಪಾರ್ಸ್ ಮಾಡಿದ ನಂತರ self.connection.recv ಗೆ ಬದಲಾಗಬೇಡಿ. ಇಲ್ಲದಿದ್ದರೆ ಆ ಸ್ಟ್ರೀಮ್ ಹಿಡಿದಿಟ್ಟಿರುವ ಬೈಟ್‌ಗಳನ್ನು ಬಿಟ್ಟು ಕೋಡ್ ಎಂದಿಗೂ ಮತ್ತೆ ಕಳುಹಿಸದ ಡೇಟಾಗಾಗಿ ಕಾಯಬಹುದು.

rfile ಅನ್ನು ಸ್ವತಃ select ಗೆ ನೀಡುವುದರಿಂದ select ಅದರ Python ಬಫರ್ ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಸಿದ್ಧತೆ API ವಸ್ತುವಿನ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಒಂದು ಮಾನ್ಯ Content-Length ಇರುವ ಮತ್ತು Transfer-Encoding ಇಲ್ಲದ ವಿನಂತಿಗೆ, ಘೋಷಿಸಿದ ಬೈಟ್ ಸಂಖ್ಯೆಯನ್ನು ನಿಖರವಾಗಿ ಬಳಸಿ, ಇನ್‌ಪುಟ್‌ನ ಅಕಾಲಿಕ ಅಂತ್ಯ ಮತ್ತು ನಿಮ್ಮ ಗಾತ್ರ ಹಾಗೂ ಸಮಯ ಮಿತಿಗಳನ್ನು ನಿರ್ವಹಿಸಿ. EOF ವರೆಗೆ ಓದಬೇಡಿ: ನಿರಂತರ ಸಂಪರ್ಕ ಬಳಸುವ ಕ್ಲೈಂಟ್ ವಿನಂತಿ ಮುಗಿದ ನಂತರವೂ ಸಂಪರ್ಕವನ್ನು ತೆರೆದಿಡಬಹುದು.

ಫ್ರೇಮಿಂಗ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿಯ ಸ್ಪಷ್ಟ ಭಾಗವಾಗಿಸಿ

ಚಂಕ್ ಮಾಡಿದ ವಿನಂತಿ ಬಾಡಿಗಳಿಗೆ ಚಂಕ್ ಮಾಡಿದ ಫ್ರೇಮಿಂಗ್ ಬೆಂಬಲ ಬೇಕು. ಇಲ್ಲದ Content-Length ಹುಡುಕಿ ಅವುಗಳನ್ನು ಓದಲಾಗದು. ಅಸ್ಪಷ್ಟ ಉದ್ದ ಮೆಟಾಡೇಟಾಗೆ ನಿರ್ದಿಷ್ಟ ತಿರಸ್ಕಾರ ಮಾರ್ಗ ಬೇಕು, ಅನುಕೂಲಕರವೆನಿಸುವ ಹೆಡರ್ ಆಯ್ಕೆ ಮಾಡುವ ಬದಲು.

ಬ್ಲಾಕಿಂಗ್ handler ಮಿತವಾದ ಓದುವಿಕೆಗಳೊಂದಿಗೆ ತನ್ನ ಸ್ಟ್ರೀಮ್ ಇಂಟರ್‌ಫೇಸ್ ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸಬಹುದು. ಈವೆಂಟ್ ಚಾಲಿತ ಪ್ರಾಕ್ಸಿಗೆ ಪಾರ್ಸರ್‌ನ ಮುಂಗಡ ಓದುವಿಕೆಯನ್ನು ಸಿದ್ಧತೆ ನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುವ ಬಫರ್ ಮಾದರಿ ಬೇಕು. ಟೈಮೌಟ್ ಬದಲಿಸುವುದರಿಂದ ಒಂದೇ socket ನ ಎರಡು ಸ್ವತಂತ್ರ ಗ್ರಾಹಕರು ಹೊಂದಾಣಿಕೆಯಾಗುವುದಿಲ್ಲ.

ಈ ನಿರ್ಣಯವು ಒಳಬರುವ ಬೈಟ್‌ಗಳನ್ನು ಎಲ್ಲಿ ಇಡಲಾಗಿದೆ ಎಂಬುದಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ. ಪ್ರಾಕ್ಸಿ ಸರಿಯಾದ ಬಾಡಿ ಬಳಸಿದ ನಂತರವೂ ಅದನ್ನು ಸ್ಥಿರವಾದ HTTP ಫ್ರೇಮಿಂಗ್‌ನೊಂದಿಗೆ ರವಾನಿಸಬೇಕು. ಪ್ರಮಾಣಿತ http.server handler ಕಾರ್ಯವಿಧಾನವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಉಪಯುಕ್ತ ಸ್ಥಳ, ಆದರೆ ಅದು ಉತ್ಪಾದನಾ ಫಾರ್ವರ್ಡ್-ಪ್ರಾಕ್ಸಿ ಅನುಷ್ಠಾನವಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು